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Abstract 

This  research  develops  and  implements  Visual  Refine,  a  graph-based  visual¬ 
ization  system,  for  the  Refine^^  wide-spectrum  formal  specification  language  and 
environment  developed  and  marketed  by  Reasoning  Systems,  Inc.  Refine  specifica¬ 
tions  are  represented  in  the  Refine  object  base  as  abstract  syntax  trees  (AST).  Using 
these  AST  representations,  one-to-one  mappings  are  defined  between  nodes  of  the 
AST  and  the  graphical  icons  of  Visual  Refine.  Visual  Refine  uses  these  mappings 
to  implement  a  set  of  formal  transformations.  Each  transformation  is  encapsulated 
within  a  Refine  rule,  and  this  set  of  rules  form  the  Visual  Refine  transformation 
system.  The  Visual  Refine  transformation  system,  in  conjunction  with  Refine  ob¬ 
ject  base  manipulation  facilities,  is  then  used  to  create  graph-based  visualizations 
of  Refine  specifications.  To  illustrate  that  visualization  aids  in  the  understanding  of 
a  formal  specification,  Visual  Refine  is  applied  to  an  example  Refine  specification. 
Finally,  it  is  shown  that  the  technology  developed  for  Visual  Refine  is  general  enough 
to  be  applied  to  any  language  that  can  be  represented  as  an  AST  in  the  Refine  object 
base.  Specifically,  the  technology  is  shown  to  be  applicable  and  beneficial  towards 
formalizing  Domain  Specific  Software  Architectures. 
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Graph-Based  Visualization  of  Formal  Specification 
and  Domain  Specific  Languages 


I.  Introduction 


1.1  Background 

Computer  software  has  infiltrated  every  aspect  of  modern  life.  And  yet,  virtu¬ 
ally  every  computer  program  ever  written  contains  errors,  anomalies,  or  peculiarities 
(11:3).  These  errors,  commonly  known  as  “bugs,”  can  not  simply  be  attributed  to 
the  people  building  modern  software  systems;  rather,  these  bugs  are  more  likely  due 
to  the  inadequacy  of  the  methods  used  to  specify,  design,  and  implement  complex 
software  systems  (11:3).  The  need  for  improvements  in  software  development  is  well 
established  (8:2  -  8),  (9:547),  (10:1  -  7),  and  (20:2  -  4);  and  yet,  improvements  in 
the  areas  of  project  management,  requirements  analysis,  top-down  problem  decom¬ 
position,  structured  programming,  abstract  data  types,  information  hiding,  program 
walk-throughs,  and  rigorous  testing  have  not  provided  the  technology  necessary  to 
ensure  that  a  program  will  function  in  the  manner  specified  by  the  software  designer; 
simply  put,  program  correctness  remains  a  problem  (11:2-3;.  The  quality  of  soft¬ 
ware  has  gotten  better,  as  a  result  of  the  above  mentioned  improvements,  but  as  the 
following  list  clearly  shows,  traditional  methods  of  developing  software  does  not,  and 
can  not,  ensure  that  software  will  perform  as  expected  when  delivered  (11:4): 

•  Space  shuttle  Discovery  flew  upside  down  during  a  laser-beam  missile  defense 
experiment  due  to  a  discrepancy  in  the  units  of  expected  data. 

•  The  first  version  of  the  F-16  navigation  software  improperly  handled  crossing 
the  equator,  causing  the  aircraft  to  fly  upside  down. 
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•  One  version  of  the  Apollo  11  software  had  the  moon’s  gravity  appearing  repul¬ 
sive  rather  than  attractive. 

•  A  computer  bug  caused  a  US  warship’s  gun  to  fire  opposite  the  intended  di¬ 
rection  during  an  exercise  off  San  Francisco  in  1982. 

•  A  series  of  accidental  radiation  overdoses  was  administered  by  cancer  therapy 
machines  in  Georgia  because  of  an  error  in  the  controlling  computer  program. 


Some  might  argue  that  more  complete  testing  of  software  systems  is  the  an¬ 
swer.  However,  exhaustive  testing  of  even  small  programs  is  not  practical.  Simple 
mathematics  show  that  even  small  programs  (fifty  conditional  branches)  would  re¬ 
quire  over  thirty-five  years  to  exhaustively  test  on  a  machine  capable  of  executing 
one  million  instructions  per  second  (ips). 
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Obviously,  testing  is  not  the  answer. 

Mills  claims  that  ninety  percent  of  errors  made  in  software  development  today 
are  probably  due  to  the  immature  methods  used  by  developers,  rather  than  to  the 
fallibility  of  the  people  involved  (14:92).  With  this  in  mind,  Mills  provides  an  ex¬ 
cellent  analogy  between  software  of  today  and  mathematics  using  Roman  numerals 
(14:91).  Until  the  discovery  of  in  place  notation,  numbers  had  to  be  treated  as  whole 
units,  rather  then  as  a  collection  of  individual  digits.  Long  division  could  only  be 
accomplished  by  highly  trained  mathematicians.  It  is  likely  that  roman  scribes  had 
“trade  secrets”  for  determining  the  quotient  and  remainder,  similar  to  the  trade  se¬ 
crets  of  today’s  programmers.  By  making  a  fundamental  change  in  the  methods  used 
(i.e.  in  place  notation),  the  problem  of  solving  complicated  long  division  problems 
was  reduced  to  several  small  steps,  each  of  which  could  be  immediately  verified.  Us¬ 
ing  this  methodology,  it  is  now  possible  for  skilled  school  children  to  solve  problems 
beyond  the  capability  of  Euclid  and  Archimedes  (14:91).  A  similar  fundamental 


change  in  the  methodology  used  to  specify,  design  and  implement  software  systems 
must  be  made  if  the  software  industry  is  to  produce  reliable  and  correct  software 
systems. 

Boehm  recognizes  errors  in  today’s  software  ais  a  problem;  however,  he  believes 
that  economics  as  well  as  increasing  requirements  for  software  are  the  major  moti¬ 
vations  for  improving  software  productivity.  Boehm  predicts  that  at  a  growth  rate 
of  approximately  twelve  percent,  the  software  costs  for  the  Department  of  Defense 
(DoD)  will  grow  from  the  1985  figure  of  $11  billion  to  a  1995  figure  of  $36  billion, 
with  national  and  worldwide  figures  increasing  to  $225  billion  and  $450  billion  re¬ 
spectively.  Figure  1.1  is  extracted  from  Boehm’s  article  (7:43)  to  better  illustrate 
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Figure  1.1.  Software  Cost  Trends  (7:figure  1) 

his  cost  trend  predictions.  Besides  the  economic  motivation,  Boehm  points  to  th<‘ 
backlog  of  software  requirements  as  another  reason  to  make  a  fundamental  change  in 
the  technology  used  to  develop  modern  software  systems.  Using  the  Air  Force  as  an 
example,  Boehm  says,  “the  Standard  Information  Systems  Center  has  identified  a 
four-year  backlog  of  unstarted  projects  representing  user-validated  software  needs" 
(7:44).  Simply  put,  industry,  using  current  methodologies,  can  not  produce  soft- 
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ware  at  a  rate  equal  to  the  demand  for  new  products.  Boehm  makes  the  following 
observations  (7:49): 

•  cost  savings  in  software  development  involve 

1.  making  individual  steps  more  efficient  via  such  capabilities  as  automated 
aids  to  software  design  analysis  or  testing; 

2.  eliminating  steps  via  such  capabilities  as  automatic  programming  or  au¬ 
tomatic  quality  assurance; 

3.  eliminating  rework  via  early  error  detection  or  via  such  capabilities  as 
rapid  prototyping  to  avoid  later  requirements  rework. 

•  further  major  cost  savings  can  be  achieved  by  reducing  the  total  number  of 
elementary  operation  steps  by  developing  products  requiring  the  creation  of 
fewer  lines  of  code. 

A  fundamental  change  in  methodology  must  be  made  in  order  to  address  the 
problems  mentioned  above.  Balzer  et  al.,  in  their  article  “Software  Technology  in 
the  1990’s:  Using  a  New  Paradigm”,  discuss  software  initiatives  of  the  Department 
of  Defense  (DoD)  and  the  direction  they  should  take.  They  compare  the  current 
software  paradigm,  commonly  called  the  waterfall  nodel  to  a  new  automation-based 
paradigm,  called  the  transformation  life  cycle  model.  Figure  1.2  illustrates  the 
current  paradigm,  upon  which  incremental,  or  evolutionary,  improvements  are  be¬ 
ing  made  (5:40).  Figure  1.3  illustrates  the  »v,'t.>mation  based  paradigm,  which  is 
based  on  the  formal  specification  of  software  ( .>.40).  Improvements  to  the  current 
paradigm  have  a  high  degree  of  probability  for  short  term  payoffs;  however,  they  are 
limited  to  the  inherent  weaknesses  of  the  paradigm  itself,  namely,  “no  technology 
for  managing  the  knowledge-intensive  activities  that  constitute  software  develop¬ 
ment  processes,”  and  “maintenance  is  performed  on  source  code”  (5:39).  Since  the 
current  paradigm  can  not  affect  these  weaknesses,  an  alternative  automation-based 
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Figure  1.2.  Current  Paradigm:  The  Waterfall  Model  (5:figure  1(b)) 


paradigm  is  put  forth  in  an  effort  to  achieve  order-of-magnitude  improvements  in 
software  production  (5:39).  The  new  paradigm  centers  around  formal  specifications, 
a  mathematically  precise  method  of  capturing  the  knowledge,  and  rationale,  of  the 
development  process.  Prototyping  and  maintenance  activities  are  now  accomplished 
early  in  the  development  life  cycle  (5:40)  so  that  errors  are  corrected  at  a  lower  cost 
(7:47  -  49).  Balzer  et  al.  discuss  many  advantages  to  this  new  paradigm  (5:41  -  44) 
but  of  importance  here  is  the  potential  for  vast  improvements  in  productivity  while 
also  substantially  improving  software  quality  and  correctness. 

Balzer  et  al.  clearly  demonstrate  the  applicability  of  their  new  paradigm  but 
fail  to  address  the  complexity  commonly  found  in  formal  specifications.  Formal  spec¬ 
ifications  state  a  system’s  requirements  in  precise  and  unambiguous  mathematical 
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Figure  1.3.  New  Paradigm:  Automation-Based  Life  Cycle  Model  (5:figure  1(a)) 

statements.  Since  all  but  the  most  simple  software  systems  require  complex  interac¬ 
tions,  a  formal  specification  also  becomes  very  complex.  Additionally,  most  software 
professionals,  and  their  users,  are  not  adequately  educated  to  correctly  interpret  the 
complex  mathematical  expressions  found  in  a  formal  specification.  Since  the  formal 
specification  is  the  cornerstone  upon  which  the  benefits  of  Balzer’s  paradigm  rely, 
the  mathematical  complexity,  which  restrain  formal  specifications  from  being  widely 
used,  must  be  made  easier  to  deal  with.  The  remaining  portions  of  this  thesis  ex¬ 
plains  the  construction  and  benefits  of  tools  and  methodologies  which  help  to  reduce 
the  complexity  of  formal  specifications.  More  specifically,  this  thesis  demonstrates 
how  visualizing  a  wide-spectrum,  formal  specification  language  improves  user  un¬ 
derstanding  and  how  this  same  visualization  technology  can  be  used  to  visualize 
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domain  specific  languages,  providing  greater  analyst  and  client  understanding  of  the 
problem. 

1.2  Problem 

1.2.1  Big  Picture  The  Air  Force  Institute  of  Technology  (AFIT),  School  of 
Engineering,  Department  of  Electrical  and  Computer  Engineering,  Formal  Meth¬ 
ods  Group  has  an  overall  research  objective  to  “investigate/develop  new  methods 
and  prototype  tools  that  contribute  to  the  construction  of  a  formal  foundation  for 
software  engineering”,  with  a  specific  objective  of  “formalization  of  requirements 
analysis  [domain  modeling],  specification,  and  design”  (3).  A  formal  environment 
for  the  development  of  software  is  currently  being  prototyped  in  support  of  the  above 
objectives.  To  be  of  greatest  use,  this  environment  must  be  able  to  import  informa¬ 
tion  from  the  informal  development  methods  in  widespread  use  today.  AFlT’s  formal 
environment  requires  an  import  facility  so  that  current  software  projects  have  a  mech¬ 
anism  to  transform  informal  specifications  and  designs  into  formal  specifications  and 
designs.  This  environment  must  also  support  the  formal  development  of  software 
systems  from  the  ground  up.  Since  informal  models  typically  represent  information 
in  a  graphical  manner,  and  since  humans  communicate  more  easily  through  visual 
or  graphical  means  (2:2-7),  AFlT’s  formal  environment  will  use  a  formal  graphical 
language  to  represent  both  syntax  and  semantics  of  the  desired  software  system. 
Once  a  software  developer  is  satisfied  with  a  system’s  formal  graphical  representa¬ 
tion,  the  environment  will  automatically,  or  at  least  semi-automatically,  produce  an 
executable  formal  specification  derived  by  compiling  the  graphical  specification.  Fig¬ 
ure  1.4  illustrates  the  relationship  between  AFlT’s  formal  environment  and  other 
external  components. 

1.2.2  Major  Subdivisions 
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Figure  1.4.  Formal  Environment  Context  Diagram 

L2.2.1  Import  Facilities  Several  informal  graphical  models  are  widely 
used  throughout  the  software  industry  for  requirements  analysis,  specification,  and 
even  software  design.  Examples  of  such  tools  include  Data  Flow  Diagrams,  Structure 
Charts,  SADT  Diagrams,  Concept  Maps,  Entity- Relationship  Diagrams,  and  many 
others.  In  order  to  support  the  formal  method  approach  to  software  engineering  in  a 
general  sense,  these  informal  models  need  to  be  transformed  into  the  formal  environ¬ 
ment  by  automated  means.  One  method  of  achieving  this  is  to  capture  the  essential 
information,  associated  with  these  abstract  models  of  software  requirements,  and 
represent  this  information  uniformly.  The  methods  and  procedures  used  to  manipu¬ 
late  the  uniform  representation  are  contained  within  an  abstract  model  manipulator 
illustrated  in  figure  1.5.  The  capture  and  transformation  of  essential  data  within 
these  informal  models  is  one  subsystem  of  AFIT’s  formal  environment. 

1.2. 2. 2  General  Transformation  Facilities  Information  contained  within 
the  common  abstract  model  must  be  transformed  into  a  formal  specification,  or 
at  least  a  template  from  which  the  formal  specification  can  be  completed.  These 
transformations,  contained  within  the  general  model  transformer,  become  another 
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subsystem  of  AFIT’s  formal  environment. 

Since  it  is  unlikely  that  the  informal  model  contained  all  of  the  necessary  infor¬ 
mation  needed  to  build  a  formal  specification,  the  transformation  from  the  abstract 
model  to  the  formal  specification  will  most  likely  produce  only  a  partial  formal  spec¬ 
ification.  The  developer  will  then  need  to  complete  the  formal  specification  using  a 
formal  specification  environment,  such  as  Refine^^. 
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Figure  1.5.  Major  Sub-Systems  of  Formal  Environment 


1.2. 2.3  Visualization  Facilities  The  final  sub-system  of  AFIT’s  formal 
environment  is  responsible  for  representing  the  formal  specification  via  a  formal 
graphical  language.  The  development  of  this  graphical  language,  along  with  a  graph- 
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ical  editor  and  bi-directional  transformation  models,  is  essential  towards  making  the 
formal  specification  more  understandable  to  current  programmers,  and  non-technical 
users  of  the  specification.  The  Refine  formal  specification  language,  developed  and 
marketed  by  Reasoning  Systems  has  been  chosen  for  use  within  AFlT’s  formal  en¬ 
vironment.  Through  the  use  of  the  Refine  Environment  and  associated  object  base 
(see  Chapter  II)  partial  and/or  completed  formal  specifications  are  generated.  These 
same  partial  and/or  completed  specifications  are  visualized  through  the  use  of  the 
visualization  facilities. 

The  primary  purpose  of  the  formal  visualization  tool  is  to  enhance  human  (an¬ 
alyst  and  client)  understanding  of  the  formal  specification.  If  this  is  to  be  achieved, 
the  diagrams  generated  by  the  graphical  language  subsystem  must  meet  the  re¬ 
quirements  for  readability  outlined  in  (16:18  -  19).  Protsko  et  al.  outline  three  main 
properties,  which  have  been  followed  to  the  greatest  extent  possible,  as  follows  (16:18 
-19): 


1.  Limited  Complexity:  Positioning  of  icons  within  the  editor  must  insure  suffi¬ 
cient  white  space  to  ensure  readability. 

2.  The  Concept  of  Flow:  Positioning  of  icons  within  the  editor  must  allow  for  the 
“flow”  inherent  with  any  specification.  For  example  the  begin  symbol  should 
be  on  the  left  or  top  of  the  diagram,  while  the  stop  symbol  should  be  on  the 
right  or  bottom  respectively. 

3.  Placement  Criteria:  To  enhance  readability,  the  editor  must  follow  certain 
placement  criteria.  For  example,  the  diagram  name  should  always  be  placed 
in  the  'jame  location  (absolute  placement),  or  icons  representing  some  result 
should  always  be  to  the  left  or  below  icons  representing  the  arguments  of  the 
calculation  (relative  placement). 

1.2.3  Objectives  of  This  Thesis  This  research  effort  is  primarily  concerned 
with  three  main  objectives: 
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1.  Develop  a  formal  graphical  specification  language  which  represents  the  Re¬ 
fine  formal  specification  language.  A  Graphical  notation  for  the  Refine  wid^  • 
spectrum  formal  specification  language  has  been  developed  by  Place  in  (15:5-1 
-  5-34).  This  notation  will  form  the  basis  of  Visual  Refine,  a  formal  graphical 
language,  and  therefore,  must  be  analyzed  for  the  following: 

•  adequate  coverage  of  the  Refine  language,  and 

•  existence  of  a  one-to-one  mapping  between  Place’s  graphical  notation  and 
the  Refine  wide-spectrum  specification  language. 

2.  Develop  and  prototype  a  generalized  mechanism  for  transforming  the  Refine 
wide-spectrum  specification  language  into  the  Visual  Refine  graphical  lan¬ 
guage.  This  objective  is  primarily  concerned  with  applying  the  technology 
developed  in  objective  number  one.  Once  Visual  Refine  is  well  defined,  it  must 
be  realized,  along  with  an  automated  set  of  transformation  tools,  to  be  useful 
as  a  visualization  tool  for  the  Refine  wide-spectrum  specification  language. 

3.  Extend  the  technology  developed  in  objectives  number  one  and  two  to  any 
formal  language  that  can  be  processed  by  the  Refine  object  base.  One  example 
of  this  type  of  extension  would  be  applying  this  visual  technology  to  a  Domain 
Specific  Language  used  in  a  formalized  Domain  Specific  Software  .\rchi lecture. 

The  first  objective  is  necessary  to  formalize  Place’s  graphical  notation,  pro¬ 
ducing  the  Visual  Refine  formal  graphical  language.  Objective  number  one  is  the 
foundation  upon  which  the  rest  of  this  research  is  built.  Objective  number  two 
demonstrates  the  usefulness  of  the  previously  developed  Visual  Refine  language. 
Visualizing  the  complex  structures,  common  to  formal  specifications,  significantly 
reduces  the  complexity  and  enhances  understanding,  thereby  making  Balzer’s  trans¬ 
formational  life  cycle  model  more  practical.  Objective  number  three  demonstrates 
the  usefulness  of  formal  language  visualization  towards  enhancing  understanding 
in  domain  specific  environments.  Together  these  objectives  fulfill  the  requirements 
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of  the  formal  visualization  subsystem  of  AFlT’s  formal  environment.  Figure  1.6 
illustrates  the  essential  components  of  this  thesis. 
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Figure  1.6.  Formal  Specification  Visualization  Tool 


1.3  Summary  of  Current  Knowledge 

Research  directed  specifically  at  formal  graphical  specification  languages  is 
extremely  rare,  indicating  the  ground  breaking  nature  of  this  type  of  work.  Of 
numerous  sources  reviewed,  only  a  few  were  found  to  contain  information  relevant 
to  the  visualization  of  formal  specifications.  Chapter  II  contains  summaries  of  these 
sources.  This  research  effort  uses  the  Refine  wide-spectrum  specification  system  (19). 
Since  this  type  of  environment  is  fairly  new,  Chapter  II  also  contains  a  synopsis  of 
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the  Refine  system,  as  well  as  an  overview  of  the  important  features  used  to  achieve 
the  objectives  of  this  research. 

1.4  Assumptions 

No  assumptions  have  been  made  in  regards  to  previous  research  efforts  or 
concurrent  research  efforts.  The  graphical  notation  presented  in  (15:5-1  -  5-62)  forms 
the  foundation  of  the  formal  graphical  language  developed;  however,  no  assumptions 
have  been  made  as  to  the  completeness  or  correctness  of  the  notation.  A  thorough 
analysis  of  Place’s  notation  is  conducted  in  Chapter  III  of  this  thesis. 

1.5  Document  Organization 

Chapter  II,  Summary  of  Current  Knowledge,  presents  a  review  of  two  founda¬ 
tional  research  efforts,  (2)  and  (15),  which  provided  the  background  needed  to  begin 
this  research  effort.  Additionally,  this  chapter  includes  a  synopsis  of  the  Refine  spec¬ 
ification  system  (19),  and  an  overview  of  important  features  used  to  formally  specify 
the  transformation  systems  developed  for  this  research. 

Chapter  III,  The  Development  of  Visual  Refine,  systematically  develops  the 
Visual  Refine  graphical  specification  language.  Beginning  with  Place’s  graphical 
notation  for  the  Refine  wide-spectrum  specification  language,  each  icon  is  formalized 
by  first  defining  its  input  and  output  ports  and  then  defining  a  one-to-one  relationship 
between  each  icon  and  its  Refine  abstract  syntax  tree  structure.  Finally,  a  set  of 
additional  icons,  necessary  for  Visual  Refine  to  function  properly,  is  developed. 

Chapter  IV,  The  Application  of  Visual  Refine,  demonstrates  the  usefulness 
of  Visual  Refine.  This  chapter  develops  a  generalized  method  to  transform  Refine 
compiled  source  code  into  a  pictorial  representation  in  Visual  Refine. 

Chapter  V,  Domain  Specific  Languages,  demonstrates  the  applicability  of 
formal  language  visualization  in  the  area  of  domain  specific  languages. 
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Chapter  VI,  Conclusions  and  Recommendations,  summarizes  the  work  accom¬ 
plished  by  this  research  with  specific  conclusions  as  to  the  benefits  and  shortcomings. 
Recommendations  for  further  research  are  also  presented  in  this  chapter. 

Following  the  text  of  this  thesis  are  several  appendices.  Appendices  A  through 
C  are  included  to  help  the  reader  better  understand  how  Place  developed  the  graphi¬ 
cal  notation  upon  which  Visual  Refine  is  based.  Appendices  D  and  E  are  the  results 
of  the  research  work  discussed  in  Chapter  III.  Appendix  F  is  the  Refine  specification 
for  the  prototype  of  the  Visual  Refine  transformation  system.  Appendices  G  and  H 
are  the  Refine  and  Visual  Refine  specifications  respectively  for  Place’s  solution  to 
Kemmerer’s  library  problem  discussed  in  Chapter  IV,  As  an  alternative  to  Place’s 
functional  oriented  solution.  Appendices  I  and  J  provide  the  Refine  and  Visual 
Refine  specification  for  Blankenship’s  object-oriented  solution  to  the  same  problem. 
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II.  Review  of  Current  Literature 


2. 1  Introduction 

Formal  specifications  are  a  fairly  new  idea  within  the  fields  of  Computer  Science 
and  Software  Engineering.  The  idea  of  visualizing  a  formal  specification  language  is 
even  newer.  For  this  reason,  very  little  has  been  written  which  directly  relates  to 
research  in  the  area  of  visualization  of  formal  specifications.  There  is  however  some 
preceding  research  which  builds  a  foundation  for  the  visualization  of  the  Refine  formal 
specification  language.  Bailor’s  research,  “Theory  for  Graph- Based  Language  Spec¬ 
ification,  Analysis,  and  Mapping  with  Application  to  the  Development  of  Parallel 
Software”,  provides  a  formal  foundation  for  transforming  between  multi-dimensional 
languages  (diagrams)  and  linear  languages  (high  level  programming  language)  (2). 
And  Place’s  research,  “The  Development  of  a  Graphical  Notation  for  the  Formal 
Specification  of  Software”,  provides  a  basis  for  the  Visual  Refine  formal  graphical 
specification  language  developed  as  part  of  this  research  (15).  This  chapter  reviews 
the  relevant  portions  of  Bailor’s  and  Place’s  work.  Since  wide-spectrum  formal  speci¬ 
fication  languages  and  environments  are  not  commonly  understood,  this  chapter  will 
also  include  an  overview  of  the  Refine  formal  specification  language  and  environment. 

2.2  Theory  for  Graph-Based  Language  Specification, 

Analysis,  and  Mapping  with  Application  to  the 

Development  of  Parallel  Software 

The  research  work  accomplished  by  Bailor  in  (2)  is  his  attempt  at,  “providing 
the  necessary  formalism,  theoretical  foundations,  and  frameworks  needed  to  develop 
formal  specification  diagrams  for  software  systems”  (2:ii).  Bailor  develops  a  formal 
language  theory  model  of  graphs  and  graph-based  languages,  which  he  calls  a  “graph 
generative  system”  (2:1-1).  He  uses  this  model  as  a  basis  for  specifying,  analyzing, 
mapping,  and  applying  graph-based  languages  in  the  specification  and  design  of  par- 
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allel  software  systems  (2:1-1),  although  the  theory  is  applicable  to  specification  and 
design  of  software  systems  in  general.  Three  chapters  of  Bailors  work  are  of  partic¬ 
ular  interest  to  this  review.  Chapter  VIII,  “Graph-  Based  Language  Mappings”  and 
Chapter  IX,  “Existence  and  Analysis  of  Meta-Level  Generating  Functions”  provide 
the  mathematical  foundation  for  graph-based  language  transformations,  and  Chap¬ 
ter  X,  “Application  of  the  Theory”,  provides  a  generalized  framework  useful  towards 
applying  the  previously  developed  theory.  The  frameworks  developed  by  Bailor  along 
with  the  supporting  theory,  form  the  necessary  theoretical  foundation  from  which 
the  current  research  is  derived.  Following  is  a  discussion  of  Bailor’s  frameworks  and 
the  supporting  theory. 

2.2. 1  Application  Frameworks  Bailor  develops  both  specific  and  general  frame¬ 
works  for  applying  his  theory  of  “Graph- Based  Generative  Systems”.  Only  the  gen¬ 
eral  frameworks  are  of  interest  to  this  review.  First  a  general  framework,  applicable 
to  the  areas  of  visual  programming,  software  development,  and  conceptual  program¬ 
ming  is  presented  (2:10-1  -  10-4).  The  primary  benefit  of  formalizing  and  using 
graph-based  languages  for  these  types  of  systems  is  their  ability  to  represent  com¬ 
plex  system,  and  software,  relationships  visually  (2:10-1).  It  is  possible  that  the 
formalized  graph-based  model  is  all  that  is  required  to  adequately  model  the  system. 
It  is  more  likely  though,  that  the  formalized  model  must  further  be  developed  into  a 
specification,  design,  and  implementation,  which  will  require  various  transformations 
from  the  original  formalized  graph-based  model  (2:10-1). 

Figure  2.1  illustrates,  in  a  general  sense,  how  graph-based  languages  can  be 
used  to  represent  several  other  formalized  languages  (2:10-2(figure  10.1)).  By  using 
the  meta-level  graph  generative  systems  discussed  in  section  2.2.2,  the  graph-based 
languages  can  be  formalized  sufficiently  enough  to  allow  a  parser  and  compiler  to  be 
constructed  which  will  recognize  graphs  from  the  specified  class  and  transform  these 
graphs  into  the  desired  specification  language  (2:10-1  -  10-3).  The  transformations 
of  interest  to  this  review  are  the  transformations  from  the  graph-based  language  into 
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Figure  2.1.  General  Application  Framework 

either  a  wide-spectrum  language  or  a  visual  programming  language.  By  using  the 
relatively  eeisy  to  use  and  understand  graph-based  language  some  of  the  difficulty  in 
using  and  understanding  wide-spectrum  languages  can  be  alleviated  (2:10-1).  When 
addressing  the  transformation  to  visual  programming  languages,  Bailor  states  that 
this  should  be  a  natural  application  of  the  theory;  specifically,  given  sufficient  detail 
about  the  syntactical  constructs  of  the  graph-based  language,  both  the  domain  of 
interest  and  the  software  specification  and  design  can  be  modeled  (2:10-3).  He  refers 
to  this  as  a  wide-spectrum,  graph-based  language  (2:10-3).  It  is  also  true  that  given 
sufficient  detail  about  the  software  specification,  a  compiler  or  translator  can  be 
developed  which  generates  a  graph-based  language.  It  is  this  inverse  approach  which 
is  important  to  the  development  of  Visual  Refine. 

Next  Bailor  provides  a  framework  to  support  the  program  transformation,  or 
automation-based,  paradigm  (2:10-4  -  10-5).  Figure  2.2  provides  an  illustration  of 
this  framework  (2:10-4  (figure  10.2)).  Using  this  framework,  the  formalized  graph- 
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Figure  2.2.  General  Framework  for  Software  Development 

based  language  is  used  to  initially  specify  the  software  system.  For  example,  a  finite 
state  machine  could  be  specified  as  a  directed  graph  using  the  graph-based  language. 
Then  through  a  series  of  transformations,  the  graph-based  language  is  converted  to  a 
wide-spectrum  language  and  finally  into  the  target  programming  language  (2:10-4). 

The  graph-based  language  can  also  be  used  to  visualize,  in  a  conceptually  easier 
manner,  the  more  complex  syntactic  structures  of  the  wide-spectrum  language,  thus 
making  wide-spectrum  languages  more  understandable  to  the  average  user.  Bailor 
points  out  that  the  syntactical  structures  of  the  formalized  graph-based  language 
must  be  mapped  to  the  syntactical  structures  of  the  wide-spectrum  language,  but 
in  order  to  specify  these  mappings  at  the  cceceptual,  mathematical,  and  implemen¬ 
tation  levels,  an  extensive  analysis  must  be  done  (2:10-4).  He  further  defines  the 
following  as  the  minimum  set  of  mappings  which  must  be  defined  (2:10-5): 

1.  Graph-Based  Syntax  to  Linear  Syntax  —  obvious  mapping  required  for  th(' 
formalized  graph-based  language  to  function  as  a  front-end  to  current  wide- 
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spectrum  languages. 

2.  Linear  Syntax  to  Graph- Based  Syntax  —  mapping  required  to  allow  the  for¬ 
malized  graph-based  language  to  function  as  a  mechanism  for  visualizing  the 
wide-spectrum  language. 

.3.  Graph-Based  Syntax  to  Graph-Based  Syntax  —  allows  for  varying  levels  of 
abstraction  within  the  formalized  graph-based  language. 

4.  Linear  Syntax  to  Linear  Syntax  —  allows  for  mappings  between  components 
which  are  not  necessarily  multidimensional. 

It  is  precisely  these  types  of  mappings  that  the  current  research  is  interested  in 
showing.  In  order  to  develop  a  visual  representation  for  either  a  formal  specification 
language,  or  a  domain  specific  language,  mappings  number  one  and  two  above  must 
be  determined. 

2.2. S  Supporting  Theory  Bailor  defines  three  levels  of  detail  at  which  lan¬ 
guage  mappings  can  be  discussed  and  four  basic  classes  of  languages  which  are  of 
interest  to  his  research.  The  levels  of  detail  are  (2:8-1  -  8-2): 

•  Conceptual  Level  —  an  informal  level  where  basic  objects/entities  within  lan¬ 
guages  are  mapped  one  to  another. 

•  Mathematical  Level  —  a  formal  level  where  a  mathematical  function,  or  rela¬ 
tion,  is  used  to  map  a  precisely  defined  domain  into  a  precisely  defined  range. 

•  Implementation  Level  —  a  formal  level,  based  on  the  mathematical  level,  where 
additional  detuls  are  included  such  that  algorithms  and  their  associated  data 
structures  can  be  used  to  implement  the  mapping. 

Although  the  conceptual  level  of  abstraction  may  be  used  for  describing  how  a  specific 
mapping  fun^'t.ions,  it  is  the  implementation  level  of  abstraction  which  is  of  most 
importance  to  this  review.  Of  the  four  basic  language  classes  which  Bailor  describes, 
only  two  are  of  importance  for  this  review;  they  are  (2:8-2): 
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•  Two  (Multi)  Dimensional,  Graph-Based  Languages  —  Two,  or  multi,  dimen¬ 
sional  representation  (a  diagram)  which  implicitly  represents  the  sets  used  to 
describe  graphs. 

•  Linear  (or  one  dimensional)  Languages  —  used  in  graph-based  language  com¬ 
piler  systems  as  possible  target  languages.  Examples  include  software  specifi¬ 
cation  languages  and  programming  languages. 

Of  particular  interest  is  Bailor’s  use  of  la  nguage  translation  functions  (2:8- 
5)  to  specify  translations  between  two  dimensional  languages  and  linear  languages. 
Conceptually  a  language  translation  function  is  a  device,  called  a  translator,  which 
takes  as  input  an  element  from  the  source  language  and  produces  an  output  which 
is  an  element  in  the  target  language  (2:8-7).  Desirable  features  of  such  a  device  are 
(2:8-7): 

•  Each  input /output  pair  within  the  translation  definition  should  be  easily  de¬ 
termined. 

•  Given  a  translation  definition,  it  should  be  possible  to  mechanically  construct 
a  translator  with  the  following  features: 

1.  Efficient  in  terms  of  both  time  and  space  requirements, 

2.  Small  size,  and 

3.  Correctness. 

Next  B2dlor  presents  “Generalized  Translation  Functions  for  Graph-Based  Lan¬ 
guages”  (2:8-8  -  8-12).  Several  functions  are  presented,  but  for  our  purposes  only  the 
translations  between  two  dimensional  languages  and  linear  languages  are  of  concern. 
There  are  two  translations  of  interest;  they  are  (2:8-11  -  8-12): 

S-Lf^U 
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meaning  a  function  (f)  such  that  a  2-Dimensional  Graph-Bcised  input  language  {Lq^) 
is  mapped  to  a  Linear  output  language  (Ll)  and 

f-LL^Lf 

meaning  a  function  (f)  such  that  a  Linear  input  language  {Li)  is  mapped  to  a 
2-Dimensional  Graph-Based  output  language  {L}P).  For  a  more  complete  descrip¬ 
tion  of  the  notation  used  by  Bailor  see  (2:8-8  -  8-9).  To  further  define  the  above 
translations,  the  syntactic  structures  contained  within  the  Linear  language  must  be 
explicitly  defined  (2:8-12). 

2.2.3  Existence  and  Analysis  of  Meta-Level  Generating  Functions  A  meta¬ 
level  language  is  simply  a  language  which  describes  another  language,  and  in  a 
sense,  they  define  a  hierarchical  structure  for  languages  themselves  (2:9-1).  Bailor 
demonstrates  the  existence  of  meta-level  generation  functions  for  graph  generative 
systems  (2:9-1).  A  minimal  set  of  rules  exists  within  a  meta- level  language,  providing 
the  ability  to  specify  a  much  larger  set  of  graphs.  Specifically,  the  derivation  of  even 
complex  graphs  can  be  carried  out  in  a  straight  forward  and  uncomplicated  manner 
by  applying  only  a  relatively  small  number  of  rules  (2:9-1).  This  type  of  language 
provides  the  user  with  an  easy  environment  to  work  in,  but  unfortunately  this  ease 
of  use  is  usually  at  the  expense  of  efficiency  (2:9-1).  According  to  Bailor,  the  benefit 
of  a  meta-level  generation  system  is  that  “it  provides  a  computational  process  that 
can  be  analyzed”  (2:9-1).  Particularly,  various  complexity  metrics  can  be  applied, 
and  relationships  between  vaurious  processes  on  the  graph  can  be  determined. 

Bailor  shows  the  existence  of  two  specific  meta-level  graph  generative  systems. 
They  are  (2:9-5  -  9-22): 

1.  Set  Theoretic  Systems,  and 

2.  Two  Dimensional  Systems. 
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These  two  systems  are  shown  to  be  equivalent.  The  mathematical  details  concerning 
these  generative  systems  are  found  in  (2:9-2  -  9-24);  however,  analysis  of  these 
generative  systems  shows  that, 


[these]  meta-level  systems  can  generate  all  graphs  with  arbitrary  but 
finite  node  and  edge  sets,  all  graphs  with  arbitrary  but  finite  degree,  all 
graphs  that  contain  arbitrary  but  finite  length  open  and  closed  walks, 
and  all  graphs  containing  an  arbitrary  but  finite  number  of  connected 
components  (2:9-25) 

Since  all  diagrams  derived  using  the  Visual  Refine  language,  explained  further 
in  Chapter  III,  can  be  defined  as  two  dimensional  graphs,  the  meta-level  generative 
functions  developed  by  Bailor  directly  apply. 

2.3  The  Development  of  a  Graphical  Notation  for 
the  Formal  Specification  of  Software 

Place’s  research  develops  a  graphical  formal  specification  language  based  on 
the  Refine  wide  spectrum  language.  Refine  formal  specifications  are  represented  in  a 
graph-based  iconic  manner,  making  the  graphical  language  much  easier  to  create  and 
manipulate  than  the  equivalent  textual  formal  specifications  (15:xiii).  Place’s  work 
is  centered  around  the  formal  transformation  life  cycle  model  developed  by  Balzer  in 
(5).  Place’s  work  is  intended  to  make  formal  specifications  more  easily  understood, 
by  visualizing  the  specification,  via  an  iconic-based  language.  If  formal  specification 
can  be  made  understandable  to  the  average  user,  then  the  formal  transformation  life 
cycle  model  could  become  the  paradigm  of  choice  for  software  development  in  the 
future. 

If  the  formal  transformation  life  cycle  model  is  to  be  used.  Place  believes  that 
the  difficulties  associated  with  understanding  formal  specifications,  the  foundation  of 
the  model,  must  be  resolved  (15:6).  Since  humans  tend  to  understand  diagrammatic 
representations  easier  than  textual  representation.  Place  concentrated  his  efforts  on 
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the  development  of  a  graphical  notation  for  the  Refine  wide-spectrum  formal  speci¬ 
fication  language  in  support  of  the  formal  transformation  life  cycle  model  (15).  Of 
importance  to  this  review  is  Chapter  five  of  Place’s  thesis,  “A  Graphical  Represen¬ 
tation  for  the  Refine  Specification  Language”  (15). 

In  order  to  represent  the  Refine  language,  Place  first  decomposed  the  language 
into  a  set  of  primitives  (15:5-2  -  5-19).  The  implicit  parse  tree  contained  in  the 
Refine  language  documentation  is  used  by  Place  to  guide  the  decomposition  (15:5- 
2).  Place  identifies  Refine’s  primitive  data  types  and  then  identifies  Refine’s  primitive 
operations,  categorizing  the  operations  by  their  operand  data  types.  He  also  provides 
a  categorization  by  operation  characteristics.  The  results  of  Place’s  decomposition 
are  contained  in  Appendices  A  and  B. 

Once  the  decomposition  was  done,  a  graphical  notation  for  Refine  was  devel¬ 
oped  (15:5-16  -  5-35).  Place  uses  rectangular  shapes  to  represent  program  data, 
circles  or  ellipses  to  represent  program  operations,  solid  arcs  to  indicate  data  flow, 
and  dashed  arcs  to  indicate  control  flow  (15:5-16  -  5-  17).  He  then  systematically 
constructs  icons  (15:5-19  -  5-35).  For  a  complete  listing  of  Place’s  graphical  notation 
see  Appendix  C.  It  is  important  to  note,  while  reviewing  Appendix  C,  that  many 
of  the  graphical  symbols  are  used  for  more  than  one  operation.  These  “overloaded” 
symbols  perform  intuitively  similar  functions  on  dissimilar  objects  (15:5-18).  If  this 
notation  is  to  be  used,  automated  tools  must  be  able  to  recognize  various  Refine 
structures  for  each  overloaded  Visual  Refine  symbol. 

The  synt£OC  of  the  graphical  language  is  presented  in  general  terms  as  follows 
(15:5-34): 


an  operator  node  must  have  a  least  one  data  flow  input  into  the  operator 
with  any  number  of  additional  data  and  control  flow  inptits,  and  that 
an  operator  must  have  at  least  one  data  flow  output  and  any  number  of 
additional  data  and  control  flow  outputs 
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Specific  syntax,  meaning  restrictions  on  the  number  of  inputs  and/or  outputs,  is 
governed  by  individual  operators  themselves. 

The  Refine  Formal  Specification  Environment 

Refine^^^  is  a  wide-spectrum  formal  specification  language  developed  and  mar¬ 
keted  by  Reasoning  Systems.  As  a  wide-spectrum  language,  Refine  is  applicable  over 
several  areas  of  software  development.  Refine  is  particularly  useful  for  modeling  sys¬ 
tem  behavior  as  part  of  the  requirement  analysis,  or  domain  modeling  functions. 
However,  because  Refine  is  an  executable  formal  specification,  once  the  systems  be¬ 
havior  is  determinea,  the  resulting  formal  specification  easily  serves  as  a  mechanism 
for  developing  the  software  design.  The  following  three  sections  describe  three  of 
the  key  components  of  the  Refine  Development  Environment,  used  to  prototype  the 
technology  developed  as  part  of  this  research.  Figure  2.3  shows  the  relationship 
between  each  of  the  following  Refine  components. 

2.4‘1  Refine  Language  end  Object  Base  Refine  consists  of  two  main  compo¬ 
nents,  the  Refine  object  base  and  the  Refine  specification  language  (19:1-2).  The 
Refine  Object  Base  maintains  a  vast  an.ount  of  information  about  the  system  being 
developed,  including  detailed  information  about  the  specifications  themselves.  The 
Refine  specification  language,  however,  is  used  to  manipulate  the  object  base,  and  by 
so  doing,  models  a  systems  behavior.  The  Refine  specification  language  is  lexically 
analyzed  and  parsed  into  an  abstract  syntax  tree  (AST).  This  AST  is  represented 
in  the  Refine  object  base  with  each  node  of  the  AST  being  represented  tis  an  object 
and  each  arc  of  the  AST  being  represented  as  an  attribute  of  the  object  (19:5-4  - 
5-22).  Refine  provides  several  facilities  for  recognizing  and  manipulating  objects. 
These  facilities  allow  the  Refine  environment  to  transform  the  formal  specification 
from  high  level  requirements  into  detailed  software  specifications,  and  even  to  im¬ 
plementation  if  desired.  The  Refine  object  base  also  facilitates  the  transformations 
discussed  above,  for  translating  linear,  or  textual,  syntax  to  the  two-dimensional. 
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Figure  2.3.  Interrelationship  Between  Refine  Components 
graph  based  syntax  of  Visual  Refine. 


2.J^.2  Intervista  Intervista  is  a  Refine  subsystem,  loaded  separately  into  the 
Refine  object  base,  used  to  create  interactive  graphical  and  textual  user  interfaces 
(18:1-1).  Although  not  overly  sophisticated,  Intervista  provides  a  capable  graph- 
based  diagraming  facility.  Four  types  of  predefined  icons  are  available  (18:7-8)  and 
they  are: 

1.  Box, 

2.  Diamond, 

3.  Ellipse,  and 

4.  Text. 

Both  dashed  and  solid  arcs  are  supported  in  Intervista.  A  wide  range  of  predefined 
functions  are  also  available  for  manipulating  windows  (18:7-6  -  7-8),  surfaces  (18:7-5, 


2-11 


7-6),  icons  (18:7-8  -  7-10),  and  links  (18:7-10  -  7-13).  Intervista  easily  provides  the 
facilities  required  to  prototype  the  visualization  technology  of  this  research. 

2.4.3  Dialect  Dialect  is  a  Refine  subsystem,  loaded  separately  into  the  Refine 
object  base,  used  to  define  and  manipulate  formal  languages.  Formal  languages  are 
input  using  a  BNF  type  high-level  syntax  description  language.  From  this  language 
description,  an  LALR(l)  parser,  pretty  printer,  and  pattern  matching  facilities  are 
automatically  produced  (17:1-2,  1-3).  Dialect  also  insc’ts  all  code  necessary  to  parse 
the  language  into  an  abstract  syntax  tree  representation  within  the  Refine  object 
base.  These  powerful  language  processing  facilities  are  essential  to  providing  an 
effective  domain  specific  modeling  and  visualization  environment. 

2.5  Concln.<iinn 

Bailor’s  work  has  provided  a  solid  theoretical  foundation  useful  for  developing 
formalized  graph-based  languages,  such  as  Visual  Refine.  He  has  also  provided  the 
necessary  frameworks  for  applying  this  theory  in  the  area  of  software  specification 
and  design;  the  actual  transformation  methods,  which  are  needed  for  these  frame- 
w'orks,  are  the  primary  subject  of  the  present  research.  Place’s  work  has  resulted  in 
a  set  of  icons  suitxbie  for  describing  the  Refine  formal  specification  language.  By 
using  the  theory  developed  by  Bailor  and  the  icons  developed  by  Place,  a  formal¬ 
ized  graph-based  language,  based  upon  the  Refine  wide-spectrum  language,  can  be 
developed  and  i?  presented  in  C  hapter  III.  This  formalized  graph-based  language, 
called  Visual  Refine,  can  then  be  used  in  support  of  Balzer’s  automation  based 
paradigm.  Graph-Based  languages  are  conceptually  easier  to  use  and  understand; 
Wide-Spectrum  languages  are  powerful  but  conceptually  difficult  to  understand.  By 
developing  formal  transformations  between  Refine  and  Visual  Refine  the  difficulty 
of  understanding  wide-spectrum  formal  specification  languages  can  be  significantly 
reduced. 
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IIL  The  Development  of  Visual  Refine 


3. 1  Introduction 

Place’s  research,  “The  Development  of  a  Graphical  Notation  for  the  Formal 
Specification  of  Software”,  develops  a  graphical  notation  which  represents  the  Refine 
wide-spectrum  formal  specification  language  (15;Chapter  5).  Place  states  that  a  one- 
to-one  and  onto  translation  scheme  exists  between  expressions  using  his  graphical 
notation  and  corresponding  Refine  expressions  (15:5-35).  Furthermore,  he  asserts 
that  after  accounting  for  the  overloading  of  certain  graphical  operators,  a  one-to-one 
correspondence  exists  between  operators  of  the  two  languages  (15:5-35).  Although 
these  statements  may  in  fact  be  true,  there  is  nothing  inherent  in  Place’s  development 
methodology,  nor  does  he  provide  any  supporting  evidence,  to  adequately  support 
such  assertions.  In  order  for  Place’s  graphical  notation  for  the  Refine  wide-spectrum 
specification  language  to  be  used  as  the  foundation  for  the  Visual  Refine  graphical 
specification  language,  it  must  first  be  shown  that  the  above  one-to-one  relationship 
exists.  In  the  few  ceises  were  ambiguity  is  found.  Place’s  notation  is  modified  to  elim¬ 
inate  the  ambiguity.  Additionally,  Place’s  notation  is  extended  to  provide  essential 
Refine,  functionality  not  originally  accounted  for  in  his  notation.  The  results  of  this 
evaluation  and  modification  of  Place’s  notation  is  a  formal  definition  of  the  Visual 
Refine  graphical  specification  language. 

This  chapter  is  divided  into  three  sections.  Section  3.2  explains  the  develop¬ 
ment  methodology  used  to  construct  the  Visual  Refine  graphical  specification  lan¬ 
guage  from  Place’s  Refine  graphical  notation.  Section  3.3  contains  a  detailed  example 
of  how  the  methodology  is  applied,  using  selected  examples  from  various  stages  in 
the  development  process.  And  finally,  section  3.4  formally  defines  the  one-to-one 
relationship  established  between  the  Visual  Refine  graphical  specification  language 
and  the  Refine  wide-spectrum  specification  language. 
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3.2  Development  Methodology 


One  of  two  possible  approaches  can  be  used  to  construct  a  visual  representa¬ 
tion  of  the  Refine  language.  Using  the  first  approach,  a  one-to-one  relationship  is 
developed  between  the  Visual  Refine  graphical  notation  and  the  explicit  Refine  text, 
referred  to  in  (19)  as  the  surface  syntax.  An  example  of  this  type  of  mapping  might 
be 


Size  (structure) 


where  structure  is  an  expression  evaluating  to  a  map,  set,  or  sequence.  To  implement 
this  type  of  approach  the  Visual  Refine  language  would  need  to  be  rigorously  defined, 
with  an  explicit  grammar  and  set  of  production  rules.  A  compiler  would  then  need 
to  be  developed  to  transform  from  the  Refine  surface  syntax  into  the  Visual  Refine 
graphical  representation.  A  separate  compiler  is  needed  for  transforming  from  Visual 
Refine  into  Refine  surface  syntax. 

Using  the  second  approach,  a  one-to-one  relationship  is  developed  between  the 
Visual  Refine  graphical  notation  and  an  alternative  intermediate  representation  of 
the  Refine  wide-spectrum  specification  language.  A  Refine  program  is  represented 
as  an  abstract  syntax  tree  (AST)  within  the  Refine  internal  object  base.  A  Visual 
Refine  program  can  also  be  represented  as  an  AST;  thus,  making  the  Refine  object 
base  representation  of  an  AST  a  good  intermediate  representation  for  both  languages. 
Because  the  Refine  environment,  and  accompanying  object  base,  can  readily  express 
both  Refine  programs  (19:5-4  -  5-22)  and  Visual  Refine  syntax  (18),  the  second 
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approach  has  been  chosen  for  use  by  this  research  effort.  Development  of  the  Visual 
Rehne  graphical  specification  language  is  explained  further  in  this  chapter  with  this 
approach  in  mind. 

Refine  — i 

Lexical 
Analysis 

Parse 

Refine 
Object 
Base 

Visual 

Refine 

Figure  3.1.  Refine  to  Visual  Refine  Transformation 

Figure  3.1  illustrates  where  Visual  Refine  fits  into  the  transformational  pro¬ 
cess.  The  greatest  benefit  of  Visual  Refine  is  derived  by  making  the  difficult  to 
understand  structures  of  the  Refine  wide-spectrum  language  more  easily  understood 
through  visualization.  Therefore,  the  visualization  of  the  object  base  becomes  a  nat¬ 
ural  representation  of  any  Refine  syntactical  structure.  The  process  of  transforming 
Refine  syntax  into  the  Refine  object  base  is  a  function  of  the  Refine  compiler,  and 
therefore  not  discussed  further  in  this  thesis.  However,  the  object  base  and  the 
Refine  language  representation  in  the  object  base  are  of  further  interest. 

Refine  represents  syntactical  structure  in  the  object  base  as  an  AST,  with  each 
node  of  the  AST  being  represented  as  an  object  and  each  arc  in  the  AST  represented 
as  an  attribute  of  an  object  (19:5-4  -  5-8).  The  Refine  environment  allows  for  general 
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access  to  this  object  base,  and  even  provides  several  functions  for  manipulating  and 
processing  the  AST  structures  within  the  object  base  (19:3-186  -  3-197).  Since  the 
Refine  environment  allows  access  to  the  parsed  representation  of  the  Refine  language, 
and  it  is  this  representation  which  Visual  Refine  is  representing,  the  production  rules 
for  Visual  Refine  are  implicitly  defined  as  being  equivalent  to  the  production  rules  of 
the  Refine  wide-spectrum  language.  Using  this  knowledge.  Visual  Refine  is  defined 
by  showing  a  one-to-one  relationship  between  icons  in  Visual  Refine  and  objects  in 
the  Refine  object  base. 

The  following  is  a  concise  set  of  steps  used  to  develop  the  Visual  Refine  graph¬ 
ical  specification  language: 

1.  Begin  with  a  clear  description  of  Place’s  graphical  notation  for  the  Refine  wide- 
spectrum  specification  language. 

2.  For  each  of  Place’s  icons,  show  the  Refine  object  base  AST  structure  for  which 
the  icon  represents. 

3.  Formalize  Place’s  icon  to  include  definitions  of  input  and  output  ports  to  each 
icon. 

4.  Define  any  additional  icons  necessary  for  general  applicability. 

5.  Define  Visual  Refine  icons  such  that  each  icon,  including  the  input  and  output 
arcs,  maps  to  one  and  only  one  Refine  object  base  AST  structure. 

The  first  three  steps  are  further  explained  in  section  3.3.  The  last  two  steps  are 
developed  in  further  detail  in  section  3.4. 

3.3  Detailed  Example 

Place’s  graphical  notation  for  the  Refine  wide-spectrum  specification  language 
provides  icons  for  a  broad  range  of  Refine  operations.  Yet  Place’s  notation  lacks  the 
formalism  necessary  to  implement  his  notation  in  a  meaningful  way.  This  section 
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provides  several  examples  to  illustrate  the  process  used  to  formalize  Place’s  graphical 
notation.  This  formal  definition  of  each  icon  is  used  in  development  of  the  Visual 
Refine  graphical  specification  language  developed  in  section  3.4. 

3.3.1  Place's  Graphical  Notation  The  first  step  towards  defining  Visual  Re¬ 
fine  is  to  list  the  icons  developed  by  Place  (15:5-16  -  5-33).  A  complete  listing  is 
contained  in  Appendix  C.  Contained  in  this  section  is  a  partial  listing  used  to  il¬ 
lustrate  the  process  followed  to  formalize  Place’s  notation.  Figure  3.2  illustrates  the 


Addition  Subtraction  Multiplication  Division 


Integer  Integer  o  , 

Division  Remainder  Coercion 


Equality  Greater  Less  Greater  Than  Less  Than 

or  Equal  to  or  Equal  to 

Figure  3.2.  Mathematical  Operations 


mathematical  operation  icons  developed  by  Place  (15:5-20).  These  icons  have  been 
chosen  for  the  example  because  they  are  conceptually  easy  to  understand  and  have 
universally  accepted  notations.  Figure  3.3  illustrates  the  set  operation  icons  devel¬ 
oped  by  Place  (15:5-24).  The  set  operation  icons  have  been  chosen  to  illustrate  how 
the  overloading  of  the  plus  (-f)  and  minus  (-)  icons  is  handled,  as  well  as  to  show’ 
the  resolution  of  non-unique  AST  structures  discussed  later. 
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Filter  Size  Empty  Test 


Arbitrary 
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Figure  3.3.  Set  Operations 


3.3.2  Refine  Abstract  Syntax  The  next  step  is  to  determine  what  the  ab¬ 
stract  syntax  structure  looks  like  for  each  icon  Place  has  defined.  To  accomplish 
this  step,  Place’s  decomposition  of  the  Refine  wide-spectrum  specification  language 
(15:Appendix  D)  and  the  Refine  users  manual  (19:3-20  -  3-150)  had  to  be  consulted. 
From  this  information,  a  determination  is  made  as  to  the  Refine  surface  syntax  in¬ 
tended  by  Place  in  his  notation.  Using  the  Refine  command  interface  (19:4-3  -  4-6), 
the  surface  syntax  previously  determined  is  parsed,  resulting  in  the  creation  of  an 
abstract  syntax  tree  representation  defined  as  the  current  object  of  the  Refine  object 
base.  To  display  an  object,  along  with  its  attributes,  the  Refine  “(pup)”  command 
(19:4-30  -  4-32)  is  used.  By  using  the  “(pup)”  command,  along  with  commands  for 
moving  within  the  object  base  (19:4-57  -  4-61),  the  abstract  syntax  tree  structure 
is  determined.  Although  the  above  procedure  may  sound  complicated,  the  Refine 
environment  makes  it  a  fairly  straightforward  process.  Appendix  D  contains  the 
abstract  syntax  tree  structures,  derived  using  the  above  methodology,  for  each  of 


3-6 


the  graphical  icons  developed  by  Place  and  listed  in  Appendix  C. 

To  further  illustrate  the  process  used,  the  multiplication  mathematical  oper¬ 
ator  and  the  subset  set  operator,  shown  in  figure  3.4,  will  be  developed  in  detail. 
Multiplication  is  listed  under  ‘Numbers’  in  Place’s  decomposition  of  the  Refine  lan¬ 
guage  by  operand  data  type  (Appendix  A),  and  is  not  shown  to  be  overloaded  in  his 
decomposition  by  operation  characteristics  (Appendix  B).  Therefore,  the  ‘Nnmbers’ 
section  of  the  Refine  Users  Manual  (19:3-20  -  .3-35)  is  consulted  to  determine  the 
intended  Refine  surface  syntax  for  the  multiplication  operation.  Similarly,  the  sub- 


( SUBSET) 


boolean 


subset-op 

Set1  Set2 


r' 

set 


set 


(MULTIPLICATION) 

^  1 
product j 

times-op 

Multiplicandst 


{any  numeric  type}* 


Figure  3.4.  Multiplication  and  Subset  Operations 

set  operator  is  listed  under  ‘sets’  in  Appendix  A,  and  not  shown  to  be  overloaded  in 
Appendix  B.  The  ‘Sets’  section  (19:3-56  -  3-77)  is  therefore  consulted  for  the  subset 
operation.  The  next  step  is  to  determine  the  most  appropriate  surface  syntax.  In 
the  case  of  multiplication,  the  most  generic,  and  least  restrictive,  surface  syntax  is 
an  asterisk  (*)  followed  by  a  left  parenthesis,  zero  or  more  numeric  items,  and  finally 
a  right  parenthesis  (19:3-26).  The  surface  syntax  for  the  subset  operation  is  always  a 
set,  followed  by  the  word  “subset”,  followed  by  another  set  of  the  same  type  (19:3-76. 
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3-77).  The  next  step  uses  the  Refine  command  interface  to  determine  the  abstract 
syntax  tree  structure. 

To  determine  the  multiplication  AST  structure,  the  command  “(#>  *()  )”, 
representative  of  a  multiplication  operation,  is  input  to  the  Refine  command  inter¬ 
face.  This  results  in  an  AST  being  built  and  represented  as  the  current  object  in  the 
Refine  environment.  The  “(pup)”  command  (19:4-30  -  4-32)  is  used  to  display  the 
current  object,  which  has  the  following  form: 


a  re::times-op 

re::cla88:  re::time8-op 
re: :multiplicand8:  {} 
re: : top-object-read:  true 


Similarly,  to  determine  the  subset  AST,  the  command  “(#>  {}  subset  {}  )”, 
representative  of  a  subset  operation,  is  input  to  the  Refine  command  interface  and 
the  resulting  object,  when  displayed,  appears  as  follows: 


a  re: :8ub8et-op 

re : : class :  re : : subset-op 
re::8et2:  #l<a  re: :literalset-op> 
re::8etl:  i2<a  re: :literal8et-op> 
re: : top-object-read:  true 

The  final  step  is  to  analyze  the  object  to  determine  the  AST  structure.  An 
analysis  of  the  above  objects  easily  produces  the  multiplication  and  subset  abstract 
syntax  tree  structures  depicted  in  figures  3.5  and  3.6.  Input  data  type,  and  resul¬ 
tant  information,  is  determined  by  reviewing  the  operational  behavior  descriptions 
contained  in  (19:3-26,  3-27,  3-76,  3-77). 

The  same  methodology  is  used  to  develop  AST  structures  for  each  icon  listed  in 
Appendix  C.  Figures  3.5  and  3.6  illustrate  the  AST  structures  for  the  icons  shown 
in  figures  3.2  and  3.3  respectively.  The  plus  (-I-),  and  minus  (-)  set  operations  icons 
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Figure  3.5.  Mathematical  Operations 

each  require  two  AST  structures  to  adequately  represent  the  intended  surface  syntax, 
denoted  by  the  dashed  boxes  in  figure  3.6.  These  same  icons  are  overloaded  with 
the  mathematical  plus  (+)  and  minus  (-)  icons,  yet  have  significantly  different  AST 
structures.  A  resolution  for  both  of  these  problems  is  discussed  in  section  3.3.4.  A 
complete  listing  of  AST  structures  for  icons  listed  in  Appendix  C  can  be  found  in 
Appendix  D. 

3.3.3  Abstract  Syntax  Notation  The  notation  used  in  figures  3.5  and  3.6,  as 
well  as  in  Appendices  D  and  E,  is  taken  from  the  Refine  users  manual  (19)  and  is 
summarized  as  follows: 
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Figure  3.6.  Set  Operations 

•  an  asterisk  (*)  means  zero  or  more  items 

•  a  single  plus  (+)  means  at  least  one,  possibly  more,  items 

•  two  pluses  (++)  mean  at  least  two,  possibly  more,  items 

•  one  or  more  items  enclosed  in  square  brackets  ([  item  ])  is  a  sequence 

•  one  or  more  items  enclosed  in  curly  brackets  ({  item  })  is  a  set 

•  a  vertical  bar  (|)  is  a  logical  OR 

•  an  ampersand  (&)  is  a  logical  AND 


3.3.4  Formalized  Graphical  Notation  Enough  information  is  now  available  to 
formally  specify  the  input  and  output  ports  for  each  of  Place’s  icons.  For  most  of 
Place’s  icons,  this  process  is  a  matter  of  simply  overlaying  the  AST  structure  with 
the  graphical  notation.  For  example,  the  multiplication  AST  structure,  presented  in 
figure  3.5,  can  have  zero  or  more  inputs  to  the  ‘times-op’  node,  denoted  by  the  set 
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containing  zero  or  more  elements.  The  ‘times-op’  node  produces  exactly  one  output, 
denoted  by  the  single  arrow,  which  is  the  product  of  all  inputs.  This  same  AST 
structure  is  represented  graphically  in  figure  3.7  by  showing  an  input  arrow  with  an 
asterisk  (*),  meaning  zero  or  more  inputs  are  possible,  and  a  single  output  arrow, 
meaning  one  and  only  one  output  is  produced.  Similarly,  the  subset  AST  structure, 
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Figure  3.7.  Mathematical  Operations 

presented  in  figure  3.6,  has  exactly  two  inputs,  denoted  by  ‘Setl’  and  ‘Set2’,  and 
produces  exactly  one  output,  of  type  boolean,  to  indicate  whether  ‘Setl’  is  a  subset 
of  ‘Set2’.  The  graphical  representation  of  subset,  shown  in  figure  3.8,  depicts  this 
same  relationship  by  illustrating  exactly  two  input  arcs  and  exactly  one  output  arc 
for  the  subset  icon. 

Unfortunately,  not  all  of  the  icons  were  as  straightforward  as  these  examples. 
The  plus  (+)  and  minus  (-)  set  operations  w'ere  viewed  by  Place  as  a  case  of  over¬ 
loading  the  mathematical  plus  (+)  and  minus  (-)  operations.  This  view  turns  out 
to  be  incorrect.  The  plus  (+)  set  operation  can  have  either  a  “plus-op”  AST  rep- 
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Figure  3.8.  Set  Operations 

resentation  or  an  “add-element-to-set-op”  AST  representation,  as  indicated  by  the 
dashed  box  in  figure  3.6.  If  the  “plus-op”  AST  representation  is  chosen  as  the  nn 
derlying  structure  for  Visual  Refine  then  an  overloaded  graphical  symbol  can  be 
used;  however,  this  choice  makes  element  addition  to  a  set  no  longer  possible.  If  the 
alternative  “add-element-to-set-op”  AST  representation  is  chosen  as  the  underlying 
structure  for  Visual  Refine  then  using  an  overloaded  icon  produces  an  ambiguity 
in  the  underlying  structure  of  this  icon.  Functionally,  the  addition  of  sets,  using  a 
“plus-op”  AST  structure,  and  the  union  of  sets,  using  the  “union-op”  AST  structure, 
is  the  same.  For  this  reason,  the  inclusion  of  a  set  addition  icon,  based  upon  the 
“plus-op”  AST  structure,  would  not  add  any  additional  capabilities  to  the  Visual 
Refine  language.  Therefore,  the  “add-element-to-set-op”  AST  structure  is  chosen 
to  represent  set  addition.  By  making  this  choice,  an  ambiguity  now  exists  in  tin* 
underlying  AST  structure  for  the  plus  (-1-)  icon.  To  resolve  this  ambiguity,  a  new 
icon  is  developed,  and  shown  in  figure  3.8,  which  represents  element  addition  to  a 
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set.  This  new  icon  represents  the  “add-element-to-set-op”  AST  structure. 

The  minus  (-)  set  operation  contains  the  same  ambiguity  problem  found  with 
the  plus  (+)  set  operation.  In  this  case,  the  dashed  box  in  figure  3.6  shows  two  similar 
AST  structures,  set  difference  ( “setdiff-op”  AST)  and  element  deletion  (“delete- 
element-from-set-op”  AST),  for  representing  the  surface  syntax  intended  by  Place. 
Both  of  these  structures  are  ambiguous  with  the  mathematical  minus  (-)  operation. 
A  choice  must  be  made  as  to  which  AST  structure  represents  set  subtraction.  To 
maintain  consistency  with  the  plus  set  operation,  the  “delete-element-from-set-op” 
AST  structure  is  used  for  Visual  Refine.  Again,  making  this  choice  ,  introduces 
ambiguity  in  the  underlying  AST  tructure  for  the  minus  (-)  icon.  To  resolve  this 
ambiguity,  a  new  icon  is  developed  which  represents  element  deletion  from  a  set.  This 
new  icon,  shown  in  figure  3.8,  has  the  “delete-element-from-set-op”  as  its  underlying 
AST  structure. 

Additionally,  figure  3.8  shows  a  notational  change  to  the  arbitrary  element 
icon.  Set  brackets  have  been  placed  around  the  question  mark  (?)  which  represents 
the  arbitrary  element  operation.  This  modification  makes  the  arbitrary  element  icon 
more  easily  recognized  as  a  set  operation. 

3.4  Formal  Definition  of  Visual  Refine 

Finally,  a  formal  definition  of  the  Visual  Refine  graphical  specifi  cation  language 
can  be  made.  Three  classes  of  icons  are  discussed: 

1.  Non-overloaded  icons  which  have  a  unique  AST  structure. 

2.  Icons  which  are  overloaded,  but  easily  resolved  due  to  similar  AST  structures. 

3.  Additional  icons  developed  for  the  Visual  Refine  graphical  specification  lan¬ 
guage. 


3-13 


The  notation  used  for  defining  the  Visual  Refine  graphical  specification  language  is 
presented  in  the  next  section,  followed  by  a  more  detailed  d-scussion  of  each  class  of 
icons  mentioned  above. 

3.4-1  Notation  for  Defining  Visual  Refine  Visual  Refine  is  defined  by  showing 
a  one-to-one  relationship  between  the  icons  of  Visual  Refine,  and  the  AST  structures 
of  the  Refine  wide-spectrum  specification  language.  To  illustrate  this  relationship 
the  following  notation  is  used.  Each  Visual  Refine  icon,  including  input  and  output 
arcs,  is  listed.  To  the  right  of  each  icon  is  a  double  headed  arrow,  used  to  symbolize 
the  one-to-one  relationship,  and  to  the  right  of  the  arrow  is  the  Refine  object  base, 
abstract  syntax  tree  structure,  associated  with  the  icon.  Figure  3.9  shows  pictorially 
the  notation  described  above.  Additional  notational  conventions  are  the  same  as 


Output  Port 


Input  Port 


ABSTRACT 


<=>  SYNTAX  TREE 
STRUCTURE 


Figure  3.9.  Notational  Definition  for  Visual  Refine 

discussed  earlier  in  section  3.3.3.  The  combination  of  the  icon  and  the  object  base 
AST  structure  form  the  formal  definition  for  the  Visual  Refine  graphical  specification 
language.  The  notation  described  above  is  followed  in  the  remaining  portions  of  this 
chapter,  as  well  as  in  Appendix  E,  which  contains  a  complete  listing  of  the  Visual 
Refine  graphical  specification  language. 
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3.4’2  Non-Overloaded  Icons  The  first  icons  defined  are  those  icons  which  are 
unique  in  Place’s  notation,  and  also  have  a  unique  AST  structure  in  Refine.  Using 
the  notation  described  above,  these  icons  are  mapped  directly  to  the  unique  AST 
structure  generated  in  section  3.3.2.  For  example,  the  multiplication  and  subset 
operators  described  in  section  3.3.4,  are  formally  defined  as  follows: 

A  ,/^uct 

I  ^  j  <=>  timesKV 
*  ^  I  Multiplicands 

( any  numsfic  type*) 


The  first  section  in  Appendix  E  contains  the  definitions  of  all  Visual  Refine  icons 
which  have  this  direct  one-to-one  relationship. 

3.4’3  Overloaded  Icons  Next,  all  non-unique,  or  overloaded,  icons  developed 
for  Visual  Refine  are  defined.  These  icon.s  require  a  further  evaluation  of  the  AST 
structures  to  determine  what,  if  any,  modifications  are  required  in  order  to  handle  the 
overloading.  All  except  the  plus  (-f )  and  minus  (-)  icons,  discussed  in  section  3.3.4, 
required  only  the  combining  of  data  types  in  the  AST  structure.  For  example  the 
‘Size’  Visual  Refine  icon  can  refer  to  the  size  o'"  a  map,  the  size  of  a  set,  or  the  size 
of  a  sequence,  as  shown  in  figure  3.10.  The  Visual  Refine  formal  definition  of  this 
icon  is  obtained  by  combining  'he  map,  set  and  sequence  data  types  with  a  logical 


3-15 


Figure  3.10.  Overloading  of  the  Size  Icon 
OR  operator  as  shown  in  the  following  formal  definition  for  the  ‘Size’  operator: 


map  I  set  I  sequence 

"SIZE" 


The  second  section  in  Appendix  E  contains  the  formal  definitions  for  overloaded 
icons.  Each  of  these  icons  was  developed  using  the  same  method  as  described  for 
the  ‘Size’  icon. 

3.4-4  Additional  icons  The  third  and  final  class  of  icons  developed  for  \^i- 
sual  Refine  are  necessary  in  order  to  provide  a  sufficient  set  of  icons  for  general  use. 
The  formalization  of  Place’s  graphical  notation  has  resulted  in  six  additional  icons 
being  developed.  Additionally,  definitions  for  literal  integers  and  strings  have  been 
developed.  Figure  3.11  illustrates  each  newly  developed  icon,  along  with  its  object 
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base  abstract  syntax  tree  structure.  The  need  to  develop  the  element  addition  and 


<=> 


/“ 


add^Ufm-fo^Mt-op 


dUBM  iimwii'toin  Mt  op 
Mnuwd^  ^  Sutxnnend 

M  tliniMiypa 


(a) 

lyukKr 


<s>  opiQion 


mM'Obiict  oCjKl 


Figure  3.11.  Additional  Icons  Developed  for  Visual  Refine 

element  subtraction  icons,  for  set  operations,  has  previously  been  discussed  in  sec¬ 
tion  3.3.4  and  need  not  be  expanded  any  further.  General  set  formers  are  commonly 
used  within  Refine  formal  specifications,  and  therefore,  a  way  of  visualizing  this  con¬ 
struct  needed  to  be  included  in  the  Visual  Refine  graphical  specification  language. 
The  object  creation,  true,  and  false  icons  were  most  likely  overlooked  during  Place's 
original  development  of  a  graphical  notation  for  the  Refine  wide-spectrum  specifica¬ 
tion  language.  They  are  necessary,  however,  to  give  Visual  Refine  a  broad  enough 
set  of  icons  for  general  purpose  use. 

Finally,  definitions  for  function  calls,  literal  integers  and  literal  strings  have 
been  developed.  The  function  icon  allows  for  an  easily  recognizable  means  of  repre¬ 
senting  modular  formal  specifications.  The  literal  definitions  are  not  icons  because 
each  integer  or  string  is  represented  differently.  However,  facilities  for  processing 
,  literal  integers  and  literal  strings  has  been  deemed  beneficial  to  the  visualization 
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process,  and  thus  they  are  included.  Figure  3.12  illustrates  the  mapping  between 
the  Refine  AST  structure  and  a  visual  notation  for  the  above  mentioned  definitions. 


Where  'NAME'  is  the  function  name. 


/ 

9999 


•MAKE* 

/ 

A  String 


<*> 


J  Ming 
Mnl-intg-op 
I  l-Ming 
•Mig 


Where  '9999'  is  the  integer 
represented  by  hinteger 


Where  ‘A  Sthng’  is  the  string 
represented  by  l-string. 


Figure  3.12.  Function  and  Literal  Definitions 


5.5  Summary 

Visual  Refine  has  been  defined  using  a  sound  methodology.  An  analysis  of  the 
graphic2il  notation,  and  the  intended  meaning  behind  the  notation,  has  been  sys¬ 
tematically  conducted.  Each  graphical  icon,  previously  developed  by  Place  (15:5-16 
-  5-33),  was  evaluated  to  determine  the  most  appropriate  underlying  Refine  AST 
structure.  Then  each  icon  was  defined  to  include  the  input  and  output  ports  neces¬ 
sary  to  represent  the  underlying  Refine  AST  structure.  Next,  a  formal  one-to-one 
mapping  between  the  formalized  version  of  Place’s  graphical  notation  and  the  un¬ 
derlying  Refine  AST  structure  was  developed.  And  finally,  several  additional  icons 
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were  created  in  order  to  give  the  Visual  Refine  language  enough  representational 
capability  to  be  useful. 

Appendix  E  contains  a  complete  and  formal  definition  for  each  icon  specified 
in  the  Visual  Refine  graphical  specification  language.  This  appendix  can  be  used  as 
a  reference  when  visualizing  Refine  formal  specifications. 
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IV.  The  Application  of  Visual  Refine 


4.1  Introduction 

This  chapter  shows  how  the  Visual  Refine  formal  graphical  specification  lan¬ 
guage,  developed  in  Chapter  III,  is  realized,  or  implemented,  using  the  Refine  formal 
specification  environment  and  wide-spectrum  language.  Once  realized.  Visual  Refine 
is  then  demonstrated  using  Kemmerer’s  library  problem  as  presented  in  (l:ix).  The 
realization  process  is  presented  first.  This  is  followed  by  a  description  of  how  to  use 
Visual  Refine  as  a  general  visualization  tool  for  Refine  formal  specifications.  Next 
section  4.4  describes  the  library  problem,  used  as  a  specific  example  of  Visual  Re¬ 
fine’s  capabilities.  And  finally,  section  4.5,  demonstrates  Visual  Refine  by  applying 
the  implementation,  developed  in  section  4.2,  to  the  library  problem  discussed  in 
section  4.4. 

4.2  Realization  of  Visual  Refine 

Visual  Refine,  as  defined  in  Chapter  III  and  Appendix  E,  could  be  used  to 
evaluate  Refine  source  specifications  by  manually  drawing  the  resulting  Visual  Refine 
specification.  However,  this  would  be  time  consuming  and  error  prone.  Therefore,  a 
semi-automated  transformation  system  is  constructed  as  a  realization  of  the  Visual 
Refine  definition  presented  in  Appendix  E.  The  first,  and  most  obvious,  step  is  to 
implement  a  transformation  for  each  of  the  Refine  operations  and  their  associated 
icons.  Visual  Refine,  by  definition,  maps  or  transforms  a  Refine  operator,  represented 
as  an  object  in  the  Refine  object  base,  to  a  graphical  icon.  Because  of  this  relation¬ 
ship,  the  Refine  ‘transform’  language  construct  is  ideal  for  constructing  Visual  Refine 
transformations.  Furthermore,  the  Refine  ‘rule’  provides  a  mechanism  for  naming 
transforms  (19:3-167),  and  therefore,  each  Visual  Refine  mapping  is  represented  as 
a  single  Refine  rule,  consisting  of  a  single  Refine  transform. 
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To  better  understand  this  relationship  several  examples  from  five  classes  of 
Visual  Refine  Icons  are  provided.  The  first  class,  top  level  icons,  specifies  the  con¬ 
struction  of  icons  which  are  always  constructed  at  the  top  level.  The  next  class, 
embedded  icons,  specifies  the  construction  of  icons  which  are  always  constructed 
as  an  input  to  a  higher-level  icon.  Thirdly,  the  class  of  boolean  icons  is  specified. 
Boolean  icons  can  be  found  at  both  the  top  level  and  embffided  level,  therefore 
they  require  special  consideration.  The  fourth  class,  binding  icons,  is  a  special  set 
of  transformations  which  specify  either  data  or  object  icons.  And  fina’ly,  the  fifth 
class,  miscellaneous  icons,  specifies  any  icons  not  covered  in  the  above  four  classes. 
The  next  five  sub-sections  discuss  in  detail  each  of  the  respective  icon  classes. 

4.S.I  Top  Level  Icons  Icons  in  this  class  represent  root  nodes  within  Refine 
abstract  syntax  trees.  They  are  referred  to  as  top  level  icons  because  they  do  not 
require  the  prior  processing  of  a  parent  object,  or  node.  Table  4.1  contains  the  icons 
belonging  to  this  class.  Although  the  erase-object  and  display  icons  are  recognized 
as  top  level  icons,  they  are  discussed  and  defined  as  part  of  the  miscellaneous  icons, 
due  to  a  similar  underlying  AST  structure. 

Table  4.1.  Visual  Refine  Top  Level  Icon  Class 


assignment-op 

enumerate-op 

erase-object 

display-object 

Consider  the  following  Visual  Refine  definition  for  an  assignment  statement  as 
an  example  of  icons  in  this  class: 
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<=> 


assignm«nt-op 


"ASSIGN" 


The  only  condition  that  must  exist  prior  to  the  creation  of  an  “ASSIGN”  icon,  is 
for  an  ‘re::assignment-op’  to  be  located  in  the  Refine  object  base.  The  check  for  this 
condition  is  specified  as  the  precondition,  or  left  hand  side,  of  the  Refine  transform. 
The  creation  of  the  “ASSIGN”  icon  is  the  post-condition,  or  right  hand  side,  of  the 
Refine  transform.  And  finally,  this  transform  is  encapsulated  in  a  Refine  ‘rule’,  with 
a  single  parameter  of  type  ‘object’  as  follows: 


rule  VR*-A8signment-0p(  X:  object  ) 
re: :as8ignment-op(  X  ) 

— > 

ri::icon(  a  )  ft  ri:  :home*‘8urface(  a  )  >  DS  ft 

ri: :  icon-type (  a  )  «  'ri:: ellipse  ft 
ri: : height-width-ratio (  a  )  «  1.0  ft 
ri::label(  a  )  >  [  "ASSIGN"  ]  ft 
ri:  :clip-icon-labol?(  a  )  ■  false  ft 
VR-Object-for-Icon(  a  )  *  X 


Functionfdly,  the  ‘assignment-op’  sets  the  value  of  the  ‘target’  attribute  equal 
to  the  value  of  the  ‘source’  attribute.  No  result  is  produced  after  carrying  out  this 
action;  therefore,  processing  this  icon  does  not  require  a  link  to  be  produced  between 
this  icon  and  its  parent  icon.  Thus  this  icon  is  always  evaluated  and  produced  at  the 
top  level.  Control  links,  or  dashed  lines,  will  be  added  later  to  show  how  top  level 
icons  interrelate.  Similarly,  the  ‘enumerate-op’  is  a  side  effect  producing  operator. 
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meaning  that  no  result  is  produced  by  the  operation.  The  ‘enumerate-op’  is  specified 
in  the  same  manner  as  the  ‘assignment-op’.  Appendix  F,  section  F.2,  contains 
complete  specifications  for  icons  within  this  class. 

4.2.2  Embedded  Icons  Embedded  icons  are  icons  that  are  always  linked  to  a 
higher  level  parent  icon.  Prior  to  creating  an  embedded  icon,  the  parent  icon  must 
first  be  processed.  Table  4.2  contains  the  icons  included  in  this  class. 


Table  4.2.  Visual  Refine  Embedded  Level  Icon  Class 


setformer-op 

literal-integer-op 

literal-string-op 

plus-op 

minus-op 

times-op 

divided-by-op 

div-op 

mod-op 

integer-to- real-op 

union-op 

intersection-op 

arbitrary-element-op 

set-to-seq-op 

first-op 

prepend-element-to-sequence-op 

insert-element-in-sequence-op 

reverse-op 

last-op 

append-element-to-sequence-op 

subsequence-op 

sequence-concatenate-op 

delete-element-from-sequence-op 

seq-to-set-op 

seq-to-map-op 

compose-op 

inverse-op 

map-to- set-op 

closure-under-op 

transitive-closure-op 

get-field-op 

filter-op 

size-op 

domain-of-definition-op 

range-op 

image-op 

add-element- to-set-op 

delete-element-from- set-op 

true-op 

false-op 

As  an  example  of  how  each  of  the  above  icons  is  specified,  consider  the  following 
definition  for  the  ‘setformer-op’  icon: 
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'set 


<=>  setformer-op 
J  Base 

any  type 

This  icon  is  used  to  represent  either  the  literal  or  the  general  set  former  operators 
in  Refine  (19:3-58  -  3-64).  In  both  cases,  the  set  former  is  a  parameter  to  another 
Refine  construct,  and  therefore  always  produces  an  embedded  icon  within  Visual 
Refine.  The  necessary  preconditions  for  the  transform  include: 

1.  the  current  object  be  a  ‘setformer-op’  or  a  ‘literalset-op’  and 

2.  the  parent  object  must  have  been  processed  prior  to  processing  the  ‘setformer- 
op’  object. 

To  determine  if  the  second  precondition  is  met,  the  attribute  ‘VR-Icon-for-Object’ 
must  be  defined  for  the  parent  object.  If  these  conditions  are  met,  then  the  transform 
produces  a  “SET”  icon  and  a  solid  line  link  from  the  newly  created  icon  to  the  icon 
which  represents  the  parent  object.  The  transform  just  described  is  encapsulated 
within  a  Refine  rule  as  shown: 

rule  VR-SetForaer-Op(  X:  object  ) 

(  re:  :eetfozser-op(  X  )  or  re: : liter alset-op(  X  )  )  t 
VR-Icon-for-Object?(  re: :parent-ezpr(  X  )  ) 

— > 

ri::icon(  a  )  t  ri: :  home-surf  ace  (  a  )  ■  DS  k 

ri: : icon-type (  a  )  ■  'ri::ellipse  k 
ri:  :height-width-ratio(  a  )  ■  1.0  k 
ri: : label (  a  )  -  [  "SET"  ]  k 

ri: : clip-icon-label? (  a  )  ■  false  k 
VR-Object-for-Icon(  a  )  ■  X  k 
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VR-Icon-for-ObjectC  X  )  *  a  ft 

ri::liiik(  b  )  ft  ri:  :home-8urface(  b  )  ■  DS  ft 

ri::source(  b  )  >  a  ft 

ri: : target (  b  )  ■ 

VR-Icon-f or-Obj  ect ( 

re: : parent -expr(  X  ))  ft 

ri: : dynamic? (b)  ■  true 


Each  icon  within  this  class  is  specified  in  the  same  manner.  See  Appendix  F,  section 
F.3,  for  a  complete  specifications  of  each  icon  listed  in  table  4.2. 

4.2.3  Boolean  Icons  The  boolean  icon  class  consists  of  icons  which  always 
produce  a  boolean  result.  This  result  can  be  interpreted  as  either  a  top  level  control 
construct,  or  as  an  embedded  level  input  to  some  higher  level  icon.  Table  4.3  contains 
ail  the  icons  included  in  the  boolean  icon  class. 


lesserorequal-op 

lesser-op 

greaterorequal-op 

greater-op 

not-op 

implies-op 

and-op 

ordered-and-op 

or-op 

ordered-or-op 

forall-op 

thereexists-op 

subset-op 

equal-op 

member-op 

empty-op 

ass 


The  boolean  ‘Not’  operator  is  used,  as  an  example,  to  describe  icon  specifica¬ 
tions  for  this  class.  The  Visual  Refine  definition  for  the  “NOT”  icon  is  as  follows: 
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<=> 


/boolean 

/ 

not-op 

I  Arg 
boolean 


Because  boolean  operators  can  be  found  at  both  the  top  and  embedded  levels  two 
separate  specifications  are  required  for  each  icon.  In  the  first  case,  the  icon  is  at 
the  top  level,  meaning  that  the  operator  is  not  part  of  a  higher  level  construct  but 
rather  is  the  highest  most,  or  root,  construct  being  sperihed.  The  precondition  for 
the  ‘Not’  operator,  in  the  example,  requires  only  that  the  current  object  be  a  ‘not¬ 
op’.  If  this  is  true,  the  post-condition  consists  only  of  the  creation  of  the  “NOT” 
icon.  When  encapsulated  into  a  Refine  ‘rule’  the  Visual  Refine  top  level  “NOT” 
operator  is  specified  as  follows: 


rule  VR-Top-Level-Not-Op(  X:  object  ) 
re: : not-op (  X  ) 

— > 

ri::icon(  a  )  t  ri: : home-surf  ace  (  a  )  >  DS  t 

ri :: icon-type (  a  )  ■  'ri;:ellipse  ft 
ri: : height-width-rat io(  a  )■  1.0  ft 
ri:: label (  a  )  «  [  "NOT"  ]  ft 

ri: : clip-icon-label? (  a  )  ■  false  ft 
VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Object(  X  )  ■  a 

In  the  second  case,  the  ‘Not’  operator  is  embedded  within  some  other,  more 
encompassing.  Refine  operator.  To  process  this  ‘Not’  operator,  a  more  stringent 
precondition  is  required.  The  current  object  must  not  only  be  a  ‘not-op’,  as  before, 
but  the  parent  object  must  also  have  been  previously  processed,  so  that  the  parent 
object  has  an  icon  defined.  As  with  the  precondition,  the  post-condition  is  also  more 
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complex  for  the  embedded  boolean  operator.  Not  only  must  the  “NOT”  icon  be 
constructed,  but  a  solid  line  link  is  constructed  from  the  “NOT”  icon  to  the  icon 
which  represents  the  parent  object.  The  embedded  level  specification  for  the  “NOT” 
icon  is  as  follows: 


rule  VR-Embedded-Not-Op(  X:  object  ) 
re::not-op(  X  )  ft 

VR-Icon-for-Object?(  re:  :parent-expr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: : home-surf ace (  a  )  >  DS  ft 

ri: : icon -type (  a  )  >  'ri : rellipse  ft 
ri: :height-vidth-ratic(  a  )  ■  1.0  ft 
ri::label(  a  )  -  [  "NOT"  ]  ft 

ri: : clip-icon-label? (  a  )  ■  false  ft 

VR-Object-for-Icon(  a  )  »  X  ft 

VR-Icon-for-Object (  X  )  ■  a  ft 

ri::link(  b  )  ft  ri:  :home-surface(  b  )  ■  DS  ft 

ri::source(  b  )  *  a  ft 

ri: : target (  b  )  ■ 

VR-Icon-f or-Ob j  ect ( 

re: : parent -expr(  X  ))  ft 

ri: : dynamic? (b)  »  true 


Each  icon  contained  within  this  class  requires  both  a  top  level  and  embedded  level 
specification.  Appendix  F,  section  F.4,  contains  complete  specifications  for  all  icons 
within  this  class. 

4-2.4  Binding  Icons  This  section  describes  the  specification  of  a  special  class 
of  icons  which  represent  either  data  or  object  references.  Six  Refine  rules,  each  dis¬ 
cussed  separately,  are  required  to  adequately  specify  these  icons.  An  internal  Visual 
Refine  structure  (binding-list)  is  used  to  maintain  a  list  of  all  data  or  object  icons 
which  are  constructed.  This  prevents  multiple  icons  from  being  built  for  multiple 
references  to  a  single  data  or  object  entity.  When  an  icon  is  built  by  a  ‘binding  icon' 
rule  it  is  inserted  into  the  ‘binding-li.^t’  structure  for  future  reference.  The  Visual 
,  Refine  binding  icon  rules  are  now  discussed;  however  the  Refine  specifications  are 
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not  include  in  this  section.  The  Refine  specification  for  each  individual  rule  may  be 
found  in  Appendix  F,  section  F.5. 

The  first  Visual  Refine  binding  icon  rule  discussed  is  “VR-Binding”.  When  a 
data  entity  is  first  introduced,  a  ‘binding’  object  is  created  in  the  abstract  syntax  tree. 
If  a  ‘binding’  object  is  recognized,  the  object  does  not  already  have  an  icon  specified, 
and  an  icon  with  the  same  name  is  not  already  in  the  ‘binding-list’  structure,  then 
the  preconditions  for  this  rule  have  been  met.  If  fired,  this  rule  produces  a  data  icon 
with  a  label  equal  to  the  ‘name’  attribute  of  the  ‘binding’  object.  Additionally,  the 
data  icon  is  added  to  the  ‘binding-list’  structure,  and  a  solid  line  link  is  constructed 
from  the  parent  object’s  icon  to  the  data  icon.  In  some  cases  a  parent  icon  does  not 
exist,  in  which  case  the  specification  of  the  link  has  no  effect. 

The  “VR-Object”  Visual  Refine  binding  icon  rule  is  similar  to  the  “VR-Binding” 
rule.  This  rule  however,  is  used  to  build  an  icon  which  represents  a  reference  to  an 
object,  rather  than  a  data  entity.  Object  references  are  recognized  as  a  Refine  ‘op¬ 
eration’  operator,  where  the  ‘rator’  attribute,  of  the  operation  object,  refers  to  an 
‘Object-Class’.  Therefore,  the  preconditions,  for  this  rule  to  fire,  include  the  recogni¬ 
tion  of  a  Refine  ‘operation’  object  and  the  determination  that  this  ‘operation’  refers 
to  an  ‘Object-Class’.  If  fired  the  rule  produces  a  Visual  Refine  object  icon  where  the 
label  is  built  from  the  ‘bindingname’  attribute  of  the  ‘rator’  attribute  of  the  ‘opera¬ 
tion’  object.  This  object  icon  is  added  to  the  ‘binding-list’  structure  and  a  solid  link 
is  constructed  from  the  object  icon  to  the  icon  representing  the  parent  object. 

When  specifying  a  reference  to  an  attribute  of  an  object  in  Refine,  an  ‘opera¬ 
tion  object  is  created  in  the  abstract  syntax  tree.  This  ‘operation’  is  distinguished 
from  other  ‘operation’  objects  by  evaluating  the  ‘rator’  attribute.  If  the  ‘rator' 
attribute  refers  to  a  ‘powermapping-op’  then  an  attribute  of  an  object  has  been 
referenced.  The  next  two  rules  discussed,  “VR-Data-With-Object-Link"  and  “VR- 
Data-Without-Object-Link”,  transform  these  types  of  references  into  Visual  Refine 
icons  and  links.  Ideally,  attribute  reference  icons  should  be  connected  not  only  to 
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the  icon  representing  the  parent  object,  but  also  to  the  object  icon  for  which  the 
attribute  belongs.  This  additional  link  is  the  difference  between  the  above  men¬ 
tioned  rules.  If  the  object  icon  has  been  previously  constructed,  then  the  link  to  the 
object  icon  can  be  made;  otherwise,  this  link  is  not  shown,  due  to  lack  of  sufficient 
information  for  its  construction. 

The  last  two  rules  in  this  class,  “VR-Binding-Ref-Build-Icon”  and  “VR-Binding- 
Ref-Link-Icon”,  are  combined  to  handle  references  to  previously  bound  variables. 
Since  it  is  common  to  make  multiple  references  to  the  same  variable  within  a  formal 
specification  segment,  it  is  desirable  to  only  produce  the  data  icon  once  and  then 
just  link  subsequent  references  to  this  icon.  The  ‘binding-list’  structure  is  used  to 
determine  whether  or  not  the  data  icon  has  been  built. 

4.2.5  Miscellaneous  Icons  Four  icons  remain  to  be  defined.  They  are  grouped 
together  to  form  a  miscellaneous  class  of  icons.  Table  4.4  contains  the  icons  included 
in  this  class. 


Table  4.4.  Visual  Refine  Miscellaneous  Icon  Class 


Nth-element-op 

erase-object 

make-object 

display-object 

Each  of  the  above  operators  is  represented  in  the  Refine  abstract  syntax  tree 
as  an  ‘operation’  object.  The  Nth-Element-Op  operator  must  have  had  the  sequence 
previously  specified  and  an  icon  constructed  for  this  sequence,  prior  to  processing 
a  reference  to  the  Nth  element  of  the  sequence.  The  ‘binding-list’  structure  is  once 
again  used  to  make  this  check.  Each  of  the  other  tree  operators  in  this  class  are 
determined  by  checking  the  ‘bindingname’  attribute  of  the  ‘rator’  attribute,  in  the 
‘operation’  object.  The  ‘erase-object’  and  ‘make-object’  have  the  same  respective 
‘bindingname’;  the  Display-Object-Op  is  determined  by  a  ‘bindingname’  of  “for¬ 
mat”,  representing  the  Lisp  language  ‘format’  statement,  used  for  output  in  Refine. 
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Complete  specifications  for  the  above  miscellaneous  icons  are  found  in  Appendix  F 
section  F.6. 


4.3  Using  Visual  Refine 

An  environment  for  transforming  Refine  specifications  has  been  developed. 
Each  rule,  described  above  and  listed  in  Appendix  F,  represents  the  transformation 
of  a  particular  Refine  object  into  a  specific  Visual  Refine  icon.  Additionally,  it  is 
presumed  that  a  Refine  specification  exists  for  a  given  application.  Figure  4.1  illus¬ 
trates  that  both  the  Visual  Refine  transformation  system  and  the  Refine  application 
are  represented  in  the  Refine  object  base.  What  appears  to  be  missing,  however,  is 


Figure  4.1.  Refine  Object  Base 

the  controlling  mechanisms  required  to  connect,  or  apply,  the  Visual  Refine  system 
to  the  Refine  application.  One  method  of  providing  these  control  mechanisms  is 
to  explicitly  develop  control  functions  for  the  Visual  Refine  transformation  system; 
however,  this  is  not  necessary  because  of  the  powerful  object  base  manipulation  fe?- 
tures  found  in  the  Refine  environment.  Three  capabilities  are  of  particular  interest. 
They  are: 
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1.  selection  of  a  particular  object  (the  MCN  function), 

2.  determination  of  what  rules  in  the  object  base  could  potentially  apply  to  the 
selected  object  (the  Rule  Search  function),  and 

3.  the  application  of  a  particular  rule  to  the  selected  object  (the  Apply  Rule 
command). 

Each  of  these  three  commands  is  described  further  below.  Additional  object  base 
manipulation  commands  can  be  found  in  (19). 

4.3.1  Generation  of  Textual  Icons  The  motivation  for  this  research  is  to  show 
the  applicability  of  visual  technologies  toward  making  formal  specifications  ecisier  to 
understand.  This  research  is  not  concerned  with  the  implementation  issues  asso¬ 
ciated  with  constructing  detailed  graphical  icons.  For  this  reason, 
annotated  with  a  word  contained  in  quotes.  This  word  represents  a 
icon,  created  for  the  Visual  Refine  prototype  system,  developed  as 
search.  For  example,  the  Visual  Refine  assignment  icon, 

4 

1 

is  prototyped  as  a  textual  icon  that  looks  like 

4 

(assign 

y 

Textual  icons  are  more  easily  implemented,  as  compared  to  the  detailed  graphical 
icons  defined  for  many  of  the  Visual  Refine  constructs.  Therefore,  the  simpler  tex- 


some  icons  are 
simpler  textual 
part  of  this  re- 
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tual  icons  have  been  used  in  the  Visual  Refine  prototype  system,  and  are  shown  in 
the  detailed  examples  found  in  section  4.5.  The  final  diagram  in  each  example,  and 
all  of  the  visualizations  in  Appendices  H  and  J,  are  depicted  using  the  graphical 
icons  of  Visual  Refine.  To  avoid  confusion,  the  textual  annotation  has  been  included, 
as  part  of  the  icon  definition.  Visual  Refine  icon  definitions  which  do  not  have  the 
textual  annotation  have  been  prototyped  as  defined. 

^.3.2  Visualization  Process  Visual  Refine  is  a  semi-automated  visualization 
tool,  used  to  visualize  formal  specifications  defined  using  the  Refine  wide-spectrum 
specification  language.  Specifically,  Refine  functions  and  rules  are  considered  the 
base,  or  root,  objects  of  interest.  And  commonly  used  Refine  operators  are  the 
elements,  or  leaf  objects,  used  to  build  up  the  visual  formal  specification.  In  order 
to  visualize  a  Refine  function  or  rule,  the  user  must  first  have  specified  the  desired 
behavior  using  the  Refine  surface  syntax  described  in  (19:Chapter  3).  Then  this 
specification  is  compiled  into  the  Refine  object  base,  where  it  can  be  processed.  To 
begin  the  visualization  process,  the  Visual  Refine  system  must  be  loaded  as  part  of 
the  Refine  environment.  This  is  accomplished  by  loading  the  following  files: 

1.  vrefine.fasl4, 

2.  vrtop.fask, 

3.  vrembed.fasl4, 

4.  vrbooln.fasl4, 

5.  vrbind.fasl4,  and 

6.  vrmisc.fasM. 

Next,  a  graphical  window  must  be  initialized.  This  is  accomplished  by  typing 
the  command  “(visual-refine)”  at  the  Refine  command  interface.  A  graphical  window 
will  appear  with  a  “STOP”  icon  defined  in  the  lower  riglit  corner  of  the  window  (see 
,  figure  4.2).  Additionally,  the  desired  Refine  function  or  rule  must  be  defined  as  the 
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current  object.  This  is  accomplished  using  the  ‘make  current  node’  (men)  command 
(19:4-58).  Type  “(men  ’desired-name)”  at  the  Refine  command  interface,  where 
desired-name  is  the  function  or  rule  to  visualize.  The  Visual  Refine  system  is  now 
ready  for  use. 

Because  Visual  Refine  is  implemented  using  Refine  rules,  the  Refine  environ¬ 
ment  can  be  used  to  determine  what  actions  are  possible  at  each  step  of  the  visu¬ 
alization.  To  make  this  determination,  the  Refine  rule  search  (rs)  command  is  used 
(19:4-66).  This  command  searches  the  Refine  object  base  for  all  rules  which  might 
apply  to  the  current  object.  Once  these  applicable  rules  are  determined,  the  Refine 
apply  rule  (ar)  command  (19:4-66)  is  used  to  select  the  desired  action.  Each  node 
in  the  Refine  AST  is  processed  using  this  approach.  Several  commands,  described 
in  the  Refine  Users  Manual  (19:4-57  -  4-61),  are  available  for  traversing  the  AST. 

Dashed  line  control  arcs  are  added  to  the  diagram  as  the  final  step.  The  Refine 
intervista  subsystem  provides  basic  tools  for  manually  creating  icons  and  arcs  (18:7- 
15  -  7-17).  In  the  case  of  the  control  arcs,  the  user  moves  the  mouse  cursor  over  the 
desired  source  icon  and  clicks  the  mouse  button.  An  “Icon  Actions”  menu  appears, 
from  which  the  “Link  to  Target”  option  is  chosen.  Then  place  the  mouse  cursor  over 
the  target  icon  to  produce  the  link.  After  the  link  is  produced,  it  must  be  edited  so 
that  it  has  the  desired  attributes  of  a  control  link.  First,  place  the  mouse  cursor  over 
the  link  and  click  the  mouse  button;  this  activates  a  “Link  Actions”  menu.  Select 
the  “Change  Type”  option,  and  then  the  “PIECEWISE-LINEAR-DASHED”  type. 
Next  select  the  link  again.  This  time  choose  the  “Edit  Label”  option  and  delete 
the  string  “New  Label”.  Continue  this  process  until  all  necessary  control  links  are 
created.  Once  the  control  links  are  in  place,  the  visualization  is  complete. 

A  general  methodology  for  using  the  Visual  Refine  formal  transformation  sys¬ 
tem  is  as  follows: 
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1.  Initialize  the  Visual  Refine  environment.  This  includes  opening  and  initializing 
a  graphics  window,  and  selecting  the  Refine  function  or  rule  to  visualize.  The 
desired  function  or  rule  is  identified  as  the  current  node. 

2.  Perform  a  rule  search.  Typically  only  one  rule  applies,  however,  if  multiple 
rules  apply,  the  user  must  determine  which,  if  any,  of  the  rules  apply. 

3.  Apply  the  desired  rule  and  determine  which  node  should  be  processed  next.  If 
the  current  node  has  children,  select  an  appropriate  child.  If  the  current  node 
is  a  leaf  node,  return  upward  in  the  AST  until  a  node  is  found  whose  children 
have  not  been  completely  processed;  select  an  unprocessed  child. 

4.  Manually  position  any  previously  created  icons,  if  desired.  Then  repeat  steps 
two,  three,  and  four  until  the  entire  AST  has  been  processed. 

5.  Manually  insert  any  necessary  control  links. 

4.4  The  Library  Problem 

Kemmerer  originally  developed  the  library  problem  as  an  example  system  for 
his  1985  article,  “Testing  Formal  Specifications  to  Detect  Design  Errors”  (13:34).  In 
1987,  the  Fourth  International  Workshop  on  Software  Specification  and  Design  in¬ 
cluded  Kemmerer’s  library  problem  in  the  problem  set  for  the  workshop,  and  defines 
the  problem  as  follows  (l:ix): 


Consider  a  small  library  database  with  the  following  transactions: 

1.  Check  out  a  copy  of  a  book  /  Return  a  copy  of  a  book; 

2.  Add  a  copy  of  a  book  to  /  Remove  a  copy  of  a  book  from  the  library; 

3.  Get  the  list  of  books  by  a  particular  author  or  in  a  particular  subject 
area; 

4.  Find  out  the  list  of  books  currently  checked  out  by  a  particular 
borrower 

5.  Find  out  what  borrower  last  checked  out  a  particular  copy  of  a  book. 
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There  are  two  types  of  users:  staff  users  and  ordinary  borrowers.  Trans¬ 
actions  1,  2,  4,  and  5  are  restricted  to  staff  users,  except  that  ordinary 
borrowers  can  perform  transaction  4  to  find  out  the  list  of  books  currently 
borrowed  by  themselves,  the  data  base  must  also  satisfy  the  following 
constraints: 

1.  All  copies  in  the  library  must  be  available  for  checkout  or  be  checked 
out. 

2.  No  copy  of  the  book  may  be  both  available  and  checked  out  at  the 
same  time. 

3.  A  borrower  may  not  have  more  than  a  predefined  number  of  books 
checked  out  at  one  time. 

From  the  above  problem  definition,  Place  developed  a  Refine  formal  specifica¬ 
tion  of  Kemmerer’s  library  problem  (15:Appendix  F).  Because  Visual  Refine  does  not 
provide  facilities  for  the  set  attribute  (set-attr)  Refine  language  construct,  Place’s 
specification  requires  slight  modifications  before  applying  Visual  Refine.  The  Refine 
set-attr  language  construct  is  a  shorthand  notation  for  assigning  values  to  several 
attributes  of  a  single  object.  Another  way  of  viewing  this  is  as  a  block  of  simple 
assignment  statements.  Therefore,  no  behavioral  change  occurs  when  the  set-attr 
constructs  are  replaced  by  a  block  of  simple  assignment  statements.  This  modi¬ 
fied  Refine  formal  specification  for  Kemmerer’s  library  problem  is  contained  in  Ap¬ 
pendix  G,  and  is  the  Refine  source  used  to  demonstrate  Visual  Refine. 

Both  a  Refine  ‘rule’  and  a  Refine  ‘function’,  from  the  library  problem,  are  used 
throughout  the  remainder  of  this  chapter,  to  illustrate  the  process  of  constructing 
Visual  Refine  representations.  A  representative  rule  from  the  library  problem  is  the 
‘Add-Book- To-Library’  rule;  this  rule  has  the  following  Refine  specification: 


rule  Add-Book-To-Library(  author  ;  string, 

title  :  string, 
subject  :  set(  string  )  ) 
empty (  {  b  I  (b:  book)  book(  b  )  k 

title-of-book(  b  )  ■  title 


)  --> 


} 
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let(  nev-book:  book  ■  make-object (  ’book  )  ) 
author-of-book  (  new-book  )  <-  author; 
title-of-book  (  new-book  )  <-  title; 

8ubject-of-book(  new-book  )  <-  subject; 
on-shelf  (  new-book  )  <-  true; 

book-out  (  new-book  )  <-  false 

Because  of  its  simple,  straight  forward  nature,  the  ‘Print-Book-Set’  function  was 
chosen  to  illustrate  in  complete  detail  the  process  of  constructing  a  Visual  Refine 
representation.  The  ‘Print-Book-Set’  function  is  specified  as  follows  in  Refine: 


function  PRINT-BOQK-SET(  set-of-books:  set (book)  )  * 
if(  empty (  set-of-books  )  )  then 

formate  true,  "This  set  of  books  is  empty  ) 
else 

enumerate  b  over  set-of-books  do 

formate  true,  "AUTHOR:  “S  ~30T  TITLE:  “S  “X 

"lOT  SUBJECT:  'S  “X", 
author-of-book (  b  ) , 
title-of-book(  b  ) , 
subject-of-book(  b  ) 

) 


4.5  Applying  Visual  Refine  to  the  Library  Problem 

This  section  discusses,  in  detail,  the  construction  of  a  Visual  Refine  represen¬ 
tation  /or  a  Refine  specification.  The  first  example  used,  is  the  above  simple  Refine 
function,  ‘Print-Book-Set’.  Following  this  detailed  example,  the  visualization  of  the 
‘Add-Book-To-Library’  Refine  rule  is  discussed.  The  visualization  of  the  ‘Add-Book- 
To-Library’  rule  is  presented  in  less  detail;  the  intent  being  to  illustrate  that  both 
Refine  functions  and  rules  can  be  visualized.  The  number  associated  with  a  Visual 
Refine  rule  is  not  necessarily  the  same  from  one  execution  to  the  next.  These  num¬ 
bers  are  dependent  upon  the  order  in  which  Refine  rule  definitions  are  compiled  and 
loaded  into  the  Refine  environment.  This  is  one  reason  why  a  rule  search  command 
is  necessary. 
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4.5.1  Print-Book-Set  The  following  discussion  assumes  that  the  user  is  fa¬ 
miliar  with  the  Refine  environment  and  specification  language.  Additionally,  it  is 
assumed  that  Refine  has  been  started  and  the  Intervista  subsystem  has  been  loaded. 
The  following  files  must  also  be  loaded: 

1.  vrefine.fask, 

2.  vrtop.fask, 

3.  vrembed.fasl4, 

4.  vrbooln.fask, 

5.  vrbind.fasl4,  and 

6.  vrmisc.fasl4. 

In  addition  to  the  above  files,  the  Refine  object  base  must  also  contain  the  compiled 
version  of  any  functions  and/or  rules  which  the  user  desires  to  visualize.  For  this 
example  the  compiled  version  of  Kemmerer’s  library  problem,  contained  in  the  file 
“library.fasl4” ,  has  been  loaded  from  the  Refine  command  line.  Once  all  the  abov(' 
files  are  loaded,  the  procedure  for  visualizing  a  function  or  rule  can  begin.  The 
following  detailed  example  will  visualize  the  ‘Print-Book-Set’  Refine  function,  as 
specified  in  section  4.4. 

The  visualization  process  is  begun  by  typing  “(visual-refine)”  at  the  Refine 
command  line  prompt,  as  follows: 

.>  (visual-rafin*) 

EE: :«UIDEFIIED* 

This  command  opens  a  graphics  window,  shown  in  figure  4.2,  where  the  results  of 
visualizing  the  ‘Print- Book- Set’  function  are  displayed. 
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Figure  4.2.  Visual  Refine  Initial  Window 


The  ‘Print- Book-Set’  function  is  represented  as  an  object  in  the  Refine  object 
base.  This  object  must  be  identified  as  the  object  of  interest.  The  ‘men’  (Make 
Current  Node)  command  is  used  as  follows  to  accomplish  this  task. 


.>  (acn  'Print-Book-Sat) 

function  PRIIT-BOOK-SET  (SET-OF-BOOKS :  sat (BOOK)) 
s  if  anptyCSET-OF-BOOKS) 

than  FOmUTCtrua,  "This  aat  of  books  is  sapty  ‘X") 
alsa  anuaarata  B  ovar  SET-OF-BOOKS 
do  FORNiT 
(tma, 

"AUTHOR:  *S  ’SOT  TITLE:  'S 

"lOT  SUBJECT:  "S  'X", 

AUTHOR-OF-BOOK(B) ,  TITLE-OF-BOOK(B) .  SUBJECT-OF-BOOK(B)) 


Note  that  the  function,  as  represented  by  the  object  base,  is  displayed  as  a  result  of 
the  ‘men’  command.  Figure  4.3  is  a  pictorial  representation  of  the  abstract  syntax 
tree  (AST)  which  represents  the  ‘Print-Book-Set’  function. 
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Figure  4.3.  Print-Book-Set:  Abstract  Syntax  Tree 
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At  this  point,  the  user  of  Visual  Refine  begins  finding  and  applying  rules  to 
the  nodes,  or  objects,  which  form  the  AST  for  the  ‘Print-Book-Set’  function.  The 
Refine  rule  search  (rs)  command  (19:4-66)  is  used  to  identify  rules  which  might  be 
applicable  to  the  current  object. 


•>  (ri) 

-  Rules  lor:  function  PRIIT-BOOK-SET  (SET-OF-BOOKS :  sst(BOOK)) 

«  if  sapty (SET-OF-BOOKS) 

then  FORMAT(tru«,  "This  sst  of  books  is  sapty  *%") 
else  snuasrats  B  over  SET-OF-BOOKS 
do  FORMAT 
(true, 

"AUTHOR:  'S  '30T  TITLE:  *S  '% 

■lOT  SUBJECT:  S 

AUTHOR-OF-BOOK(B).  TITLE-OF-BOOK(B) .  SUBJECT-OF-BOOK(B))  - 
3)  VR-VFUICTIOI-OP 


The  Refine  apply  rule  (ar)  command  (19:4-66)  is  then  used  to  apply  the  desired  rule 
to  the  current  object. 


.>  (ar  3) 

Rule  successfully  applied. 

function  PRIIT-BOOK-SET  (SET-OF-BOOKS:  set(BOOK)) 

*  if  eapty(SET-OF-BOOKS) 

then  FORNAT(true,  "This  set  of  books  is  eapty  *X") 
else  enuaerate  B  over  SET-OF-BOOKS 
do  FORMAT 
(true, 

"AUTHOR:  'S  '30T  TITLE:  "S  'X 

*10T  SUBJECT:  "S  "X", 

AUTHOR-OF-BOOK(B),  TITLE-OF-BOOK(B) ,  SUBJECT-OF-BOOK(B)) 


The  Refine  ‘pup’  command  (19:4-30)  is  used  to  print  the  current  object  in  a  format 
where  each  of  the  defined  attributes  for  that  object  can  be  identified. 


.>  (pup) 

PRIIT-BOOK-SET  -  the  re:  :vf unction-op 
re : : class :  re : : vf unction-op 
naae:  print-book-set 
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r«:  :vl&-bindiiig:  #1<PRIIT-B00K-SET  -  a  re : :  bindiiig> 
re::loraala:  [i2<SET-0F-B00KS  -  a  re:  :bisding>] 
re:: body:  •3<a  re: :conditional-op> 

re:  unction:  (DEFUI  PRIIT-BOOK-SET  (SET-OF-BOOKS)  ...) 

re:  :flow-inlo-lor-del:  'C#4<a  re:  :flov-dattuB>,  #6<a  re:  :floB-datuB>,  ..} 

re: :conpilations:  {#6<a  re: :coBpilation>} 

re: :coBpiled-okay?:  true 

re: : type-error?:  falie 

re: : top-object-read:  true 

vr-icon-for-object:  #7<an  ri::icon> 


By  reviewing  the  attributes  the  user  of  Visual  Refine  is  able  to  determine  which 
attributes  must  be  processed  as  child  nodes  in  the  AST.  For  a  ‘re::vfunction-op\ 
only  the  ‘re::formals’  and  ‘re::bo  Jj’  attributes  need  to  be  processed  (refer  to  Figure 
4.3).  For  the  ‘Print-Book-Set’  example,  the  ‘re::formals’  attribute  is  processed  first. 


.  >  ra : :  lomala 

var  SET-OF-BOOKS:  sat (BOOK) 

By  typing  the  attribute  name  at  the  Refine  command  line,  the  current  object  is 
changed  to  the  object  representing  the  input  attribute.  The  rule  search  (rs)  and 
apply  rule  (ar)  commands  are  once  again  used  to  identify  and  select  an  applicable 
rule  for  the  new  current  object,  an  ‘re::binding’  object. 


•>  (ra) 

-  Rulaa  for:  var  SET-OF-BOOKS:  sat(BOOK)  - 
81)  VR-BIIDIIG 
.>  (ar  81) 

Rula  auccassfully  appliad. 
va:  SET-OF-BOOKS:  aat(BOOK) 


When  the  attribute  being  processed  is  a  set  or  sequence  valued  attribute,  as  is  the 
case  for  ‘re::formals’,  the  Refine  next  (nx)  and  back  (bk)  commands  (19:4-7))  are 
used  to  traverse  each  element  in  the  set  or  sequence.  Additionally,  if  the  ntti  item  of 
a  sequence  is  desired,  the  integer  n  can  be  used  to  directly  traverse  to  that  object. 
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•  >  (nx) 


In  the  above  example,  the  next  (nx)  command  resulted  in  no  object  being  returned, 
indicated  by  the  lack  of  a  Refine  program  segment  being  printed.  Therefore,  the 
entire  sequence  representing  the  attribute  ‘re::formals’  has  been  processed.  To  return 
to  the  top  level  object  for  the  set  or  sequence,  the  integer  zero  is  input  at  the  Refine 
command  line. 


.>  0 

function  PRIIT-BOOK-SET  (SET-OF-BOOKS:  s«t(B00X)) 

«  if  MptyC SET-OF-BOOKS) 

th«n  FORNAT(tru«,  "This  aot  of  books  is  ssipty  *%") 

•Iss  snuHsrst*  B  ovsr  SET-OF-BOOKS 
do  FORMAT 

(trus.  "AUTHOR:  'S  *30T  TITLE:  *S  ’lOT  SUBJECT:  'S 
AUTHOR-OF-BOOK(B),  TXTLE-OF-BOOK(B) ,  SUBJECT-OF-BOOK(B)) 


Figure  4.4  shows  the  statvis  of  the  Visual  Refine  process  after  the  ‘re::formals‘ 
attribute  has  been  processed.  All  icons,  except  for  the  ‘STOP’  and  ‘START',  are 
originally  placed  in  the  lower  left  hand  corner  of  the  window.  The  default  diagram 
mouse  handler  (18:7-15  -  7-16)  is  used  to  place  the  icons  wherever  desired  by  the 
Visual  Refine  User. 

The  body  of  the  ‘Print-Book-Set’  function  can  now  be  processed.  Traversing  to 
the  ‘re::body’  attribute  of  the  “vfunction-op”  object  (refer  to  Figure  4.3),  and  using 
the  rule  search  (rs)  command,  to  process  the  new  current  node,  a  ‘conditional-oj)' 
object,  results  in  the  following: 


.  >  rs : :  body 

if  saptyfSET-OF-BOOKS) 

than  FORNATCtrus,  "This  s«t  of  books  is  sapty  *X") 
alas  snuasrats  B  ovsr  SET-OF-BOOKS 
do  FORMAT 
(trus, 

"AUTHOR:  'S  "SOT  TITLE:  "S  *X 
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Figure  4.4.  Print-Book-Set:  After  Processing  of  Formal  Parameters 

*10T  SUBJECT:  'S  ’V\ 

AUTHOR-OF-BOOK(B),  TITLE-OF-BOOK(B) ,  SUBJECT-OF-BOOK(B)) 

.>  (rt) 

-  Rules  lor:  11  •■pty(SET-OF-BOOKS) 
then  FORNAT(trus,  "This  sst  ol  books  is  snpty  '%") 
else  snuasrsts  B  over  SET-OF-BOOKS 
do  FORMAT 
(true, 

"AUTHOR:  'S  'SOT  TITLE:  'S  ’% 

-lOT  SUBJECT:  'S  'X", 

AUTHOR-OF-BOOK(B) ,  TITLE-OF-BOOK(B) ,  SUBJECT-OF-BOOK(B))  - 


The  rule  search  (rs)  command  did  not  provide  any  applicable  rules  for  this  object. 
Therefore,  no  Visual  Refine  processing  is  required.  The  (pup)  command  shows  the 
current  object  to  be  a  ‘re::conditional-op’,  which  indeed  does  not  require  any  pro¬ 
cessing. 

Therefore,  the  ‘re::condition-actions’  attribute  is  selected  to  continue  the  visu¬ 
alization. 
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.>  (pup) 

a  r«: : conditional-op 

ra::claas:  ra: : conditional -op 

parant-axpr:  #8<PIIIIT-B00K-SET  -  tha  ra:  :vlunction-op> 

ra: :alaa-clauaa:  #9<an  ra: :anuaarata-op> 

ra: :condition-actiona :  CilO<a  ra: :condit ion-act ion-op>] 


Once  again,  applying  the  rule  search  (rs)  command  reveals  that  the  ‘re::condition- 
action-op’  does  not  require  any  Visual  Refine  processing,  so,  the  (pup)  command  is 
again  used  to  select  the  ‘rericondition-cl’  attribute  for  further  processing. 


.>  ra: : condition-actions 
aaptyCSET-OF-BOOfCS) 

than  FORNATCtrua,  "This  sat  of  books  is  anpty  *%") 

•>  (rs) 

-  Rulas  for:  aBpty(SET-OF-BOOKS) 

than  F01U(AT(trua,  "This  sat  of  books  is  aapty  *X")  - 

.>  (pup) 

a  ra: : condition-action-op 

ra : : class :  ra : : condition-action-op 
parant-axpr:  t3<a  ra: :conditional-op> 
ra:  :action-cl:  flKan  ra:  :oparation> 
ra: :condition-cl:  #12<an  ra : : aapty-op> 

.>  ra: :condition-cl 
aBpty(SET-OF-BOOKS) 


The  ‘Print-Book-Set’  AST  has  now  been  traversed  to  the  ‘re::empty-op’  node  (refer 
to  Figure  4.3.  The  rule  search  (rs)  command  reveals  that  processing  is  required. 
The  ‘re::empty-op’  can  be  processed  as  follows: 


.>  (rs) 

-  Rulas  for:  aBpty(SET-OF-BOOKS)  - 

79)  TR-TOP-LEVEL-BIIPTY-OP 

80)  VR-ENBEDDED-EMPTY-QP 
.>  (ar  79) 

Rula  succassfully  appliad. 
aBpty(SET-OF-BOOXS) 


The  (pup)  command  reveals  that  the  ‘re::base’  attribute  needs  to  be  selected  for 
processing.  The  selection  is  made  and  the  attribute  is  processed  in  the  same  manner 
as  before. 
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.>  (p^.p) 

an  ra:  :«ipty-op 

ra : :  clut :  ra : :  anpty-op 
parant-axpr:  #10<a  ra: : condition-act ion-op> 
ra::basa:  #13<SET-0F-B00KS  -  a  ra: :binding-raf> 
vr-icon-for-objact:  #14<an  ri::icon> 

.>  ra: :baaa 
SET-OF-BOOKS 
•>  (ra) 

-  Rulas  for:  SET-OF-BOOKS  - 
86)  VR-BIIDIIG-REF-LIIK-ICOI 
.>  (ur  86) 

Rula  succaaafully  appliad. 

SET-OF-BOOKS 


The  (pup)  command  is  used  to  show  the  attributes  of  the  ‘re::binding-ref’  ob¬ 
ject.  No  AST  attributes  remain  (refer  to  Figure  4.3);  therefore,  processing  of  the 
‘re::condition-cl’  attribute  of  the  ‘re::condition-action-op’  object  has  concluded.  The 
next  step  is  to  return  to  the  top  level  object  and  process  another  attribute.  In 
this  case  (refer  to  Figure  4.3),  the  ‘re::action-cr  attribute,  an  ‘re::operation’  object, 
requires  processing  next. 


.>  (pup) 

SET-OF-BOOKS  -  a  ra : :  binding-raf 
ra : :  class :  ra :  :binding-ral 
parant-axpr:  *12<an  ra:  :aBipty-op> 
ra : :  bindingnaaa :  sat-of -books 
ra::raf-to:  #2<SET-OF-BOOKS  -  a  ra::binding> 

.>  0 

aapty(SET-OF-BOOKS) 

.>  0 

aMpty(SET-OF-BOOKS) 

than  FORMiT(traa,  "This  sat  of  books  is  aapty  *%") 
.>  ra: :action-cl 

FORMATCtma,  "This  sat  of  books  is  oapty  '%") 


The  following  rule  search  (rs)  reveals  several  possible  applicable  rules.  The 
user  must  decide  which  rule  is  most  applicable.  Since  a  format  statement  is  used  to 
display  text,  the  ‘VR-DISPLAY-OBJECT-OP’  rule  is  chosen. 
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.>  (ri) 

-  Rules  for:  FORNAT(trus,  "This  set  of  books  is  sapty  '%”}  - 

82)  VR-OBJECT 

83)  VR-DATA-WITi-OBJECT-LIIK 

84)  VR-OATA-VITEOUT-OBJECT-LIIK 

87)  VR-ITH-ELEMEIT-OP 

88)  VR-ERASE-OBJECT-QP 

89)  VR-MAKE-OBJECT-OP 

90)  VR-DISPLAY-OBJECT-OP 
.>  (ur  90) 

Rulo  successfully  applied. 

FORNAT(true,  "This  set  of  books  is  empty  *%") 


To  visualize  what  is  displayed,  the  ‘re::aps'  attribute  of  the  ‘re::operation’  object 
must  be  processed  further.  The  text  being  displayed  is  the  second  element  in  the 
‘re::aps’  sequence.  It  is  therefore  located  and  processed. 


. >  rs : : aps 

(trua  "This  sat  of  books  is  aapty  *%") 

.>  2 

"This  sat  of  books  is  aapty  *X" 

•>  (rs) 

-  Rulas  for:  "This  sat  of  books  is  aapty  - 
10)  VR-LITERAL-STRIIG-OP 
.>  (ar  10) 

Rula  succassfully  appliad. 

"This  sat  of  books  is  aapty  *X" 


No  further  processing  is  required  for  the  ‘re::condition-action-op’  attribute  of 
the  ‘re:;conditional-op’  object  (refer  to  Figure  4.3).  Figure  4.5  shows  the  results  of 
visualization  thus  far. 

The  next  step  is  to  return  to  the  'rc::conditional-op’  object  and  select  the 
‘re::else-cl’  attribute,  an  ‘enumerate-op’  object,  for  processing  (refer  to  Figure  4.3). 


.>  0 

F0RNAT(trua,  "This  sat  of  books  is  aapty  '%") 

.>  0 

aapty (SET-OF-BOOKS) 

than  FORNATCtrua,  "This  sat  of  books  is  aapty  *X") 
.>  0 
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/ 


/ 


Figure  4.5.  Print-Book-Set:  After  Completion  of  Conditional  Clause 
if  •■pty(SBT-OF-BOOKS) 

th«n  FORNAT(tru«,  “This  sst  of  books  is  smpty  ‘X") 

•Is*  •nuB«rat«  B  ov«r  SET-OF-BOOKS 
do  FORMAT 
(tru«, 

"AUTHOR:  'S  *30T  TITLE:  *S  'X 

‘lOT  SUBJECT:  'S  ’X", 

AUTHOR-OF-BOLICCB)  ,  TITLE-OF-BOOK(B) ,  SUBJECT-OF-BOOK(B)  ) 

.>  r«: :«ls«-clstts« 

•niui«rst«  B  OT«r  SET-OF-BOOKS 
do  FORMAT 

"AUTIOR:  'S  '30T  TITLE:  *S  'X 

-lOT  SUBJECT:  'S  'X", 

AUTHOR-OF-BOOK(B) .  TITLE-OF-BOOK(B),  SUBJECT-OF-BOOX(B)) 

As  before,  the  Refine  rule  search  (rs)  and  apply  rule  (ar)  commands  are  used  to  select 
and  apply  the  appropriate  rules  to  the  ‘re::enumerate-op’  object.  The  traversal  and 
processing  of  the  ‘re::baseset’  attribute  of  the  ‘re::enumerate-op’  object  is  performed 
in  the  same  manner  that  the  ‘re::base’  attribute  of  the  ‘re::empty-op’  object  was 
before. 
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.>  (r«) 

-  Rules  for:  snuasrats  B  over  SET-OF-BOOKS 
do  FORNIT 

(true, 

"AUTHOR:  'S  '30T  TITLE:  “S  “% 

'lOT  SUBJECT:  'S  '7,", 

AUTHOR-OF-BOOK(B).  TITLE-OF-BOOK(B) .  SUBJECT-OF-BOOK(B))  - 
8)  VR-EMUNERATE-OP 
.>  (ar  8) 

Rule  successfully  applied, 
enuaerate  B  over  SET-OF-BOOKS 
do  FORMAT 
(true, 

"AUTHOR:  *S  '30T  TITLE:  'S  '% 

”10T  SUBJECT:  ‘S  *7.", 

AUTHOR-OF-BOOK(B) ,  TITLE-OF-BOOK(B).  SUBJECT-OF-BOOK(B)) 

.>  (pup) 

an  re : : enuaerate-op 

re : : class :  re : : enuaerate-op 
parent-expr:  #3<a  re: :conditional-op> 
re::itervar:  #20<B  -  a  re::binding> 
re::baseset:  i21<SET-0F-B00KS  -  a  re: : binding-ref > 
re: :consuaer:  #22<an  re: :operation> 
vr-icon-for-object:  #23<an  ri::icon> 

.>  re: :baseset 
SET-OF-BOOKS 
.>  (rs) 

-  Rules  for:  SET-OF-BOOKS  - 
86)  VR-BIIOIIG-REF-LIIK-ICOI 
.>  (ar  86) 

Rule  successfully  applied. 

SET-OF-BOOKS 
.>  (pup) 

SET-OF-BOOKS  -  a  re :: binding-ref 
re : : class :  re : : binding-ref 
parent-expr:  *9<an  re:  :enuBerate-op> 
re : : bindingnaae :  set-of-books 
re:: ref -to:  #2<SET-0F-BL3KS  -  a  re: :binding> 


The  (pup)  command  is  used  to  show  the  attributes  of  the  ‘re::binding-ref'  ob¬ 
ject.  No  AST  attributes  remain  (refer  to  Figure  4.3);  therefore,  processing  of  the 
‘re::baseset’  attribute  of  the  ‘re:;enumerate-op’  object  has  concluded.  Returning  to 
the  ‘re::enumerate-op’  object,  the  ‘re::consumer’  attribute  is  chosen  to  continue  pro¬ 
cessing  (refer  to  Figure  4.3).  This  is  handled  in  much  the  same  manner  as  the 
‘FORMAT’  statement  above,  except  the  text  portion  is  now  represented  as  three 
data  objects,  rather  than  as  a  literal  text  string. 
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.>  0 

•nua«rat«  B  OT«r  SET-OF-BOOKS 
do  FQUIAT 
(truo, 

'•AUTHOR:  *S  ‘BOT  TITLE:  *S 

'lOT  SUBJECT:  'S 

AUTHOR-OF-BOOK(B) .  TITLE-OF-BOOK(B) ,  SUBJECT-OF-BOOK(B)) 
. >  r« : : coniuBor 
FORMAT 
(tra«, 

"AUTHOR:  'S  'SOT  TITLE:  "S  'X 

■lOT  SUBJECT:  'S  *X", 

AUTBOR-OF-BOOK(B).  TITLE-OF-BOOK(B) .  SUBJECT-OF-BOOK(B)) 

•>  (ra) 

-  Rulos  for:  FORMAT 
(trua, 

"AUTHOR:  'S  ‘30T  TITLE:  ‘S  'X 

“lOT  SUBJECT:  "S  *X", 

AUTHOR-OF-BOOK(B) ,  TITLE-OF-BOOK(B) .  SUBJECT-OF-BOOK(B))  - 

82)  VR-OBJECT 

83)  VR-DATA-VITH-OBJECT-LinC 

84)  VR-DATA-HITHOUT-OBJECT-LIHK 

87)  VR-HTH-ELEMEIT-OP 

88)  VR-ERASE-OBJECT-OP 

89)  VR-MAKE>OBJECT-OP 

90)  VR-DISPLAY-OBJECT-OP 
.>  (ar  90) 

Rula  succatafully  appliad. 

FORMAT 

(trua, 

"AUTHOR:  'S  *30T  TITLE:  'S  'X 

•lOT  SUBJECT:  'S  'X", 

AUTHOR-OF-BOOK(B) ,  TITLE-OF-BOOK(B) ,  SUBJECT-OF-BOOK(B)) 


Because  the  three  data  objects  more  accurately  illustrate  the  desired  output,  pro 
cessing  of  the  third  through  the  last  elements  in  the  ‘re::aps’  sequence  is  more  ap 
propriate. 


.>  ra: :aps 
(trua 

"AUTHOR:  S  'SOT  TITLE:  'S  'X 

■lOT  SUBJECT:  'S  ’X" 

AUTHOR-OF-BOOK(B)  TITLE-OF-BOOK(B)  SUBJECT-OF-BOOX(B)) 
.>  3 

AUTBOR-OF-BOOK(B) 

.>  (ra) 

-  Rttlaa  for:  AUTHOR-OF-BOOK(B)  - 
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82)  VR-OBJECT 

83)  VR-Dm-WITH-OBJECT-LIIK 

84)  VR-DATA-WITHOUT-OBJECT-LIIK 

87)  VR-iTH-ELEHEIT-OP 

88)  VR-ERASE-OBJECT-OP 

89)  VR-NAKE-OBJECT-OP 

90)  VR-DISPLAY-OBJECT-OP 
.>  (ar  84) 

Rule  tuccvssfttlly  applied . 
A(}THOR-OF-BOOK(B) 

•>  (nx) 

TITLE-OF-BOOK(B) 

.>  (ar  84) 

Rula  succasalully  appliad. 
TITLE-OF-BOOK(B) 

•>  (nx) 

SUBJECT-QF-BOOK(B) 

.>  (ar  84) 

Rula  succaaaYully  appliad. 
SUBJECT-OF-BOOK(B) 

.>  (nx) 


Figure  4.6.  Print- Book- Set:  Complete  Processing  of  Abstract  Syntax  Tree 


Figure  4.7.  Print-Book-Set:  Using  Visual  Refine  Implementation  Icons 

No  further  processing  of  the  ‘Print-Book-Set’  AST  is  required  (refer  to  Figure 
4.3).  Figure  4.6  shows  the  state  of  the  Visual  Refine  processing  to  this  point. 
The  only  thing  left  to  make  the  visualization  complete,  is  the  addition  of  logical 
control  paths.  These  control  paths  are  provided  manually,  using  the  default  diagram 
mouse  handler  provided  by  Intervista  (18:7-15  -  7-.16).  A  more  automated  process  of 
constructing  the  control  links  could  be  developed  by  including  processing  capabilities 
for  non-icon  producing  Refine  AST  operators.  This  capability  has  not  been  included 
in  Visual  Refine  at  this  time. 

The  completed  diagram,  as  represented  using  the  textual  implementation  icons, 
is  illustrated  in  Figure  4.7.  Figure  4.8  shows  what  the  visualization  would  look  like 
using  the  more  complicated  Visual  Refine  icons  defined  in  Appendix  E. 

4.5.2  Add- Book-To- Library  The  ‘Add-Book-to-Libra-y’  Refine  rule  is  visual¬ 
ized  next,  in  significantly  less  detail.  This  discussion  is  primarily  for  the  purpose  of 
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Figure  4.8.  Print- Book- Set:  Using  Actual  Visual  Refine  Icons 


demonstrating  Visual  Refine’s  capability  to  visualize  rules  as  well  as  functions.  For 
that  reason,  only  the  beginning  steps  and  final  results  for  visualizing  the  ‘.4dd-Book- 
To-Library’  rule  are  presented.  To  begin,  Refine  is  loaded,  including  Intervista  and 
Visual  Refine,  as  before.  The  ‘Add-Book- To-Library’  rule  has  also  been  loaded  as 
part  of  the  Iibrary.fasl4  file.  As  in  the  case  of  functions,  the  Refine  make  current 
node  (men)  command  is  used  to  define  the  object  of  interest  as  the  root  node  to  the 
‘Add-Book-To-Library’  abstract  syntax  tree. 


.>  (acn  'Add-Book-To-Libzary) 
ml*  AOD-BOOK-TO-LIBIURY 

(AUTHOR:  STRUG,  TITLE:  STRIIG,  SUBJECT:  ■•t(STRIIG)) 
#«pty 

({B  I  (B:  BOOK) 

BOOX(B)  A  TITLE-OF-BOOX(B)  «  TITLE}) 

— >  (l«t  (lEH-BOOX:  BOOK  >  MAXE-OBJECT( 'BOOK)) 
AUTHOR-OF-BOOXdEV-BOOX)  <-  AUTHOR; 
TITLE-OF-BOOX(IEU-BOOX)  <-  TITLE; 
SUBJECT-OF-BOOX(IEV-BOOX)  <-  SUBJECT; 
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OI-SIELF(IEV-BOOK)  <-  tru*; 

BOOX-OUT(nV-BOOX)  <-  fait*) 

.>  (vitual-r*fin*) 

RE:  :*UIDEFIIED* 

And  finally,  like  before,  the  Visual  Refine  environment  is  started  by  typing  “(visual- 
refine)”  at  the  Refine  command  line.  The  first  difference  between  functions  and 
rules  is  noticed  during  the  first  issuance  of  the  rule  search  (rs)  command.  Instead 
of  the  “VR-VFUNCTION-OP”  rule  being  identified,  the  “VR-RULE-OP”  rule  is 
identified.  The  application  of  “VR-RULE-OP”,  however,  has  the  same  results  as 
that  of  “VR-VFUNCTION-OP”. 


.>  (ri) 

-  Rul*i  for:  rul*  AOD-BOOX-TO-LIBRARY 

(AUTHOR:  STRUG.  TITLE:  STRUG,  SUBJECT:  t*t(STRII6)) 
•■pty 

({B  I  (B:  BOOK) 

BOOX(B)  *  TITLE-OF>BOOK(B)  *  TITLE}) 

— >  (l*t  (lEV-BOOK;  BOOX  «  NAKB-OBJECT( 'BOOX)) 
AUTHOR-OF-BOOXCIEV-BOOK)  <-  AUTHOR; 
TITLE-OF-BOOX(IEH-BOOR)  <-  TITLE; 
SUBJECT-OF-BOOK(1EH>BOOK)  <-  SUBJECT; 
OI-SHELF(IEH-BOOX)  <-  tru*; 

BOOX-OUT(IEH-BOOX)  <-  fait*)  - 
2)  VR-RULE-OP 


Next  a  (pup)  command  is  issued  to  determine  what  attributes  need  to  be  processed. 
As  in  the  ‘vfunction-op’,  an  ‘re::formaIs’  attribute  must  be  processed,  in  order  to 
visualize  the  formal  parauneter  list  for  the  Refine  rule.  Instead  of  an  ‘re::body’ 
attribute,  the  Refine  rule  has  an  ‘re::ruleexpr’  attribute  which  represents  the  single 
transform  body  of  the  Refine  rule  construct.  The  rest  of  the  attributes  are  not 
important  for  visualization. 


.>  (pup) 

ADD-BOOX-TO-LIBRARY  -  th*  r*::rul*-op 
r*:: class:  r*::rul*-op 
naa*:  add-book- to-library 
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r«:  :vln**bindiiig:  fKADD-BOOK-TO-LIBRARY  -  a  r«:  :binding> 
ra::lorBala:  Ci2<AUTE0Il  -  a  ra:  :binding>.  #3<TITLE  -  a  ra : : binding> ,  . .] 
ra:  :nilaaxpr:  #4<a  ra:  :nila-iBpl-op> 

ra:  :liip-fanetion:  (OEFUl  ADD-BOOK-TO-LIBRARY  (AUTHOR  TITLE  SUBJECT)  ...) 
ra:  :flow-inYo~for’‘del:  {f5<a  ra:  :flo*-datiui>,  i6<a  ra : :  llo«-datuB> ,  ..} 
ra:  :altar-load-fona:  {(RE: : SET-RULE-APPLICABILITY-IIFO  'ADD-BOOK-TO-LIBRARY 
'RE::AIY  'RE:*UIOEFIIED*  '(LAMBDA  (AUTHOR  TITLE  SUBJECT)  (HULL  (LET 
((REVAR::"SETVAR-0  HID)  (REFIIE-LOOP:  :LOOP  REFIIE-LOOP : : FOR  B  REFIIE-LOOP : : IM 
(RE::ELENEITS*  (RE::GSET  BOOK))  REFIIE-LOOP :: DO  (RE:: IF!  (RE: :STRIIG-EqUAL-l 
TITLE  (RE::DB-GET?  B  'TITLE-OF-BOOK))  RE::THEI  (SETQ  REVAR: :— SETVAR-0  (RE::IF! 
(RE::NEMq  B  REVAR: :— SETVAR-0)  RE::THEI  REVAR ::— SETVAR-0  RE::ELSE  (COIS  B 
REVAR: : —SETVAR-0) ))) )  REVAR: :— SETVAR-0))))} 
ra: :coBpilations:  {#7<a  ra: :coapilation>} 
ra : : coapilad-okay ? :  trua 
ra: :typa-arror?:  falsa 
ra: :top-objact-raad:  trua 
vr-icon-lor-objact:  #8<aii  ri::icon> 


The  ‘re:;forrnals’  attribute  is  processed  in  exactly  the  same  manner  as  described 
for  the  ‘Print-Book-Set’  function  above.  For  this  reason,  the  discussion  will  now  turn 
to  the  processing  of  the  ‘re::ruleexpr’ attribute.  The  traversal  to  this  attributes  node 
is  made,  and  a  rule  search  performed  to  process  the  ‘re::ruleexpr’  attribute. 


.>  ra::rulaazpr 
aapty 

({B  I  (B:  BOOK) 

BOOK(B)  A  TITLE-OF-BOOK (B)  «  TITLE}) 

— >  (lat  (lEV-BOOK:  BOOK  *  NAKE-OBJECT('BOOK)) 
AUTHOR-OF-BOOK(IEV-BOOK)  <-  AUTHOR; 
TITLE-OF-BOOK(IEW-BOOK)  <-  TITLE; 
SUBJECT-OF-BOOK(IEH-BOOK)  <-  SUBJECT; 
Ol-SHELF(IEH-BOOK)  <-  trua; 
BOOK-OUT(IBV-BOOK)  <-  falsa) 

.>  (rs) 

-  Rolas  for:  aapty 
({B  I  (B:  BOOK) 

BOOK(B)  ft  TITLE-OF-BOOK (B)  *  TITLE}) 

— >  (lat  (lEV-BOOK:  BOOK  >  NAKE-OBJECT( 'BOOK) ) 
AUTHOR-OF-BOOK(IEV-BOOK)  <-  AUTHOR; 
TITLE-OF-BOOK(IE¥-BOOK)  <-  TITLE; 
SUBJECT-OF-BOOK(IEH-BOOK)  <-  SUBJECT; 
OI-SHELF(IEV-BOOK)  <-  trua; 
BOOK-OUT(IEU-BOOK)  <-  falsa)  - 
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The  rule  search  (rs)  command  does  not  identify  any  rules  as  being  applicable  to 
process  this  node.  Therefore,  the  (pup)  command  is  used  to  determine  further 
processing. 


.>  (pup) 

a  r« : : rul«-iapl-op 

r« : :  dais :  ra : :  rula-iapl-op 

par«nt-«zpr:  #9<ADD-B00K-T0-LIBRARY  -  the  re::rule-op> 
re: : consequent:  #10<a  re: :bind-op> 
re :: antecedent :  #ll<tn  re: :eBpty-op> 


The  (pup)  command  reveals  two  attributes  require  processing.  The  ‘re::antecedent’ 
attribute,  referring  to  the  left  hand  side  of  the  transform,  is  processed  first. 


.>  re: : antecedent 
eapty 

({B  I  (B:  BOOK) 

BOOK(B)  t  TITLE-OF-BOOK(B)  «  TITLE}) 

•>  (re) 

-  Rules  lor:  eapty 
({B  I  (B:  BOOK) 

BOOK(B)  R  TITLE-OF-BOOK(B)  =  TITLE})  - 

79)  VR-TOP-LEVEL-EMPTY-OP 

80)  VR-EMBEDDED-EMPTY-OP 


Since  no  icon  was  produced  for  the  parent  object,  a  top  level  icon  is  needed  to 
begin  the  processing  of  the  ‘re::antecedent’  attribute.  The  rest  of  the  nodes  in  the 
‘re::antecedent’  attribute  abstract  syntax  sub-tree  are  processed  in  much  the  same 
manner  as  discussed  for  the  ‘Print-Book-Set’  function.  Figure  4.9  shows  the  results 
after  processing  the  entire  ‘re::antecedent’  attribute. 

After  the  ‘re::antecedent’  attribute  is  processed,  the  ‘re::consequent’  attribute 
needs  processing.  The  traversal  is  made  and  a  rule  search  (rs)  command  issued. 


. >  re : : consequent 

let  (lEU-BOOX:  BOOK  »  NAKE-0BJECT( 'BOOK)) 
AUTHOR-OF-BOOK(IEW-BOOK)  <-  AUTHOR; 
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Figure  4.9.  Add-Book-To-Library:  After  Processing  of  the  Antecedent 

TITLE-OF-BOOK(IEW-BOOK)  <-  TITLE; 

SUBJECT-OF-BOOK(IEW-BOOK)  <-  SUBJECT; 

OI-SHELF(IEV-BOOK)  <-  true; 

BOOK-OUT(IEW-BOOK)  <-  false 
.>  (rs) 

-  Rules  for:  let  (lEV-BOOK:  BOOK  «  NAKE-OBJECT('BOOX)) 
AUTHOR-OF-BOOK(IEV-BOOK}  <-  AUTHOR; 

TITLE-OF-BOOK(IEH-BOOK)  <-  TITLE; 

SUBJECT-OF-BOOK(IEV-BOOK)  <-  SUBJECT; 

OI-SHELF(IEV-BOOK)  <-  true; 

BOOK-OUT(IEV-BOOK)  <-  false  - 


Once  again  the  rule  search  (rs)  command  fails  to  provide  an  applicable  rule  to  process 
the  node.  Therefore,  the  (pup)  command  is  used  to  determine  further  processing. 


.>  (pup) 
a  re: : bind-op 

re : : class :  re : : bind-op 

parent-ezpr:  #4<a  re: :rule-inpl-op> 

re: : bindings:  {*27<IEW-B00K  -  a  re : : binding>} 

re:: body:  #28<a  re : : block-op> 
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Figure  4.10.  Add- Book-To- Library:  After  Processing  of  the  Consequent 


In  this  case,  the  ‘re:: bindings’  attribute  is  processed  in  much  the  same  manner  as  the 
‘re;;formals’  attribute  discussed  above.  Following  the  process' ng  of  the  ‘re::bindings' 
attribute  the  ‘re::body’  attribute  is  traversed  to  and  processed. 


. >  re : ; body 

AUTHOR-OF-BOOK(IEV-BOOK)  <-  AUTHOR; 
TITLE-OF-BOOK(IEH-BOOK)  <-  TITLE; 
SUBJECT-OF-BOOKCIEV-BOOK)  <-  SUBJECT; 
OI-SHELF(IEV-BOOK)  <-  true; 

BOOK-OUT(IEV-BOOK)  <-  false 
.>  (rs) 

>  Rules  for:  AUTIOR-OF-BOOK(IEV-BOOK)  <-  AUTHOR; 
TITLB-OF-BOOK(IEW-BOOK)  <-  TITLE; 
SUBJECT-OF-BOOK(IEV-BOOK)  <-  SUBJECT; 
OI-SHELF(IEV-BOOK)  <-  true; 

BOOK-OUT (lEV-BOOK)  <-  false  - 


Again,  the  rule  search  comes  up  empty,  indicating  that  further  traversal  is  required 
before  further  visualization  can  occur.  The  (pup)  command  shows  this  to  be  true. 
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.>  (pup) 
a  r«: : block-op 

r« : : clan :  ra : : block-op 
paront-azpr:  tlO<a  ro::bind-op> 

r«::8t«p«:  [*29<an  ra: :assigsa«nt-op>,  *30<an  rt: :assigna«nt-op>,  ..] 


Figure  4.11,  Add-Book- To-Library:  Intervista  Implementation  Icons 


Processing  of  the  ‘re::steps’  attribute  consists  of  processing  a  sequence  of  ‘re::assignniont- 
op’  objects  or  nodes.  This  is  accomplish  in  a  manner  similar  to  that  discussed  above, 
and  is  therefore  not  discussed  any  further.  After  the  ‘re::steps’  attribute  has  been 
processed,  the  ‘re::consequent’  attribute  is  complete.  Figure  4.10  shows  the  visual¬ 
ization  at  this  point. 

The  abstract  syntax  tree  for  the  ‘Add-Book-To-Library’  Refine  rule  has  now 
been  completely  traversed  and  visualized.  The  only  task  remaining  to  complete 
the  visualization  is  to  add  the  control  links  between  the  top  level  icons.  Figure 
4.11  illustrates  the  completed  visualization  using  the  textual  icons  implemented  in 
Intervista.  The  Visual  Refine  visualization  is  illustrated  in  figure  4.12.  This  is  what 


4-39 


Figure  4.12.  Add- Book-To- Library:  Visual  Refine  Visualizaiion 

the  visualization  would  look  like  if  the  more  complicated  icons  of  Visual  Refine  had 
been  implemented. 

4.6  An  Automated  Approach  to  Diagram  Generation 

The  above  described  technique  for  generating  a  graph-based  visualization  of  a 
formal  specification  requires  a  significant  amount  of  manual  intervention.  A  knowl¬ 
edge  of  the  underlying  abstract  syntax  tree  structure  is  also  required  to  effectively 
produce  a  visualization.  This  section  suggests  a  methodology  which  would  produce 
the  visualization  in  an  automated  manner.  Time  constraints,  prevent  the  actual 
implementation  of  the  described  methodology. 

The  Refine  ‘preorder-transform’  function  (19:3-195,  3-196)  provides  a  natu¬ 
ral  means  of  automating  the  visualization  process.  Given  an  object,  representing 
the  root  node  of  an  abstract  syntax  tree,  and  a  sequence  of  rules,  representing  the 
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transformation  system,  the  ‘preorder-transform’  function  will  apply  the  rules  to  the 
abstract  syntax  tree  in  a  top-down  fashion.  If  a  rule  is  successfully  applied,  the 
‘preorder-transform’  function  begins  again,  starting  with  the  object  that  weis  pro¬ 
duced  by  the  previously  fired  rule,  (19:3-1951  In  order  to  automate  Visual  Refine, 
using  this  function,  two  tasks  must  be  accomplished: 

1.  Each  rule  must  be  modified  to  include  a  check  on  the  left  hand  side  of  the 
transform,  which  determines  if  the  current  object  has  already  been  processed. 
This  check  is  required  to  prevent  the  ‘preorder-transform’  function  from  firing 
the  same  rule  over  and  over  without  traversing  to  a  child  node  in  the  abstract 
syntax  tree. 

2.  An  analysis  of  the  Visual  Refine  transformation  system  must  be  made  to  de¬ 
termine  if  two  or  more  rules  can  be  applicable  at  any  one  time.  If  it  is  not 
possible  to  define  the  rules  so  that  only  one  rule  is  applicable  at  any  given 
time,  then  a  determination  must  be  made  as  to  which  rule  should  come  first 
in  the  sequence  of  rules. 

By  accomplishing  the  above  tasks,  an  automated  diagram  generation  is  pos¬ 
sible.  However,  the  layout  of  the  diagram  would  still  require  a  manual  process.  To 
completely  automate  the  visualization  process,  an  automatic  diagram  layout  algo¬ 
rithm  needs  to  be  developed  as  well.  The  algorithm  should  take  as  inputs,  a  set 
of  icons  and  a  set  of  links,  and  produce  as  output  the  same  sets  with  modified  po¬ 
sition  attributes.  A  rudimentary  diagram  layout  algorithm  was  attempted  by  this 
research  without  success.  Even  an  unsophisticated  layout  rapidly  became  too  com¬ 
plicated  a  task  to  be  accomplished  within  the  scope  of  this  research.  Therefore,  the 
development  of  a  diagram  layout  algorithm  is  left  as  an  interesting  future  research 
item. 
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^.7  Summary 

The  Visual  Refine  language,  as  defined  in  Appendix  E,  has  now  been  imple¬ 
mented,  Each  icon  defined  in  Appendix  E  has  been  implemented  as  one  or  more 
Refine  transformations.  Together,  this  set  of  transformations  form  the  Visual  Refine 
graphical  formal  specification  language,  or  transformation  system.  Given  a  Refine 
formal  specification,  such  as  Place's  solution  to  Kemmerer’s  library  problem,  Vi¬ 
sual  Refine  transforms  the  complex  mathematical  structures  found  in  the  Refine 
language  into  a  more  e2isily  understood  visual  representation.  Concurrent  research 
by  Blankenship  (6:Appendix  G)  has  provided  an  object  oriented  decomposition  and 
solution  to  Kemmerer’s  library  problem.  Appendices  1  and  J  provide  an  alternative 
Refine  solution  and  Visual  Refine  representation  respectively.  This  alternative  is 
included  as  another  example  of  Visual  Refine’s  capabilities. 
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V.  Domain  Specific  Languages 


5. 1  Introduction 

Chapters  III  and  IV  have  provided  a  methodology  for  visualizing  formal  lan¬ 
guages,  using  the  Refine  specification  environment.  Although  the  visualization  of 
Refine  is  useful,  it  is  accomplished  at  a  low  level  of  abstraction;  representing  Refine 
language  constructs,  rather  then  “real  world”  objects  and  relationships.  To  be  of 
greatest  use,  this  newly  developed  visualization  technology,  needs  to  be  applied  at 
higher  levels  of  abstraction.  One  way  of  achieving  more  appropriate  levels  of  abstrac¬ 
tion,  is  through  the  use  of  Domain  Specific  languages.  Domain  Specific  languages 
describe  systems  using  terminology  from  the  domain  of  interest;  thus,  visualization 
of  constructs  from  within  this  language  results  in  icons  which  represent  “real  world” 
items  of  interest.  Therefore,  Domain  Specific  languages  naturally  provide  an  appro¬ 
priate  level  of  abstraction  for  describing  systems  from  within  a  certain  domain. 

To  make  this  new  visualization  technology  more  beneficial,  an  object-oriented 
Domain  Specific  language  needs  to  be  developed.  This  language,  when  parsed,  must 
result  in  an  abstract  syntax  tree  representation  in  a  formal  object  base  such  as  the 
one  provided  by  Refine.  Once  the  language  is  represented  in  the  object  base,  the  pre¬ 
viously  developed  visualization  technologies  can  be  used  to  develop  and  implement 
a  visual  language  representation,  and  visual  transformation  system,  for  the  Domain 
Specific  language;  thus,  a  visualization  at  an  appropriate  level  of  abstraction.  Sec¬ 
tion  5.2  discusses  the  application  of  this  concept  to  Domain  Specific  Software  Archi¬ 
tectures.  This  is  followed  by  a  discussion  in  section  5.3  on  a  general  methodology 
for  visual  support  for  a  Domain  Specific  Software  Architecture. 

5.2  Domain  Specific  Software  Architecture 

Domain  Specific  Software  Architectures  (DSSA)  have  great  potential  as  a 
means  of  establishing  a  framew’ork  for  performing  object-oriented  requiremei  ts  anal- 
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ysis,  specification,  and  design.  Typically,  DSSA’s  do  not  provide  a  formal  means  of 
capturing  the  requirements  analysis,  specification,  and  design  information.  Also 
DSSA’s  do  not  provide  a  means  of  manipulating  the  information  in  a  formal  way. 
To  address  these  shortcomings,  the  DSSA  should  be  modeled  within  a  formal  en¬ 
vironment,  such  as  Refine.  A  formal  Domain  Model,  along  with  a  formal  Object 
Specification  language,  is  used  to  capture  both  the  structure  and  behavior  of  DSSA 
software  components.  The  formal  environment  is  then  used  to  manipulate  the  cap¬ 
tured  information  in  various  ways.  By  imposing  formalism  upon  the  DSSA,  this 
promising  methodology  can  be  greatly  enhanced  in  a  powerful  way  (4). 

To  begin  construction  of  this  formal  DSSA,  a  general  configuration  must  be  de¬ 
termined.  Figure  5.1  illustrates  a  general  configuration  developed  in  support  of  this 
and  future  research.  To  capture  the  structure  and  behavior  of  software  components, 
the  software  engineer  describes  (specifies)  each  component  using  the  Object  Speci¬ 
fication  language.  The  Object  Specification  language  is  part  of  the  Domain  Model, 
which  transforms  the  input  specification  into  an  object  base  representation.  The 
Domain  Model  also  is  used  to  capture  the  interrelationships  between  various  aspects 
of  the  DSSA;  thus  the  DSSA  Formalized  Object  Base  has  effectively  captured  the 
structure  and  behavior  of  the  DSSA  including  the  software  (domain)  components, 
relationships  between  components,  and  relationship  within  the  DSSA. 

Through  the  use  of  an  object  base  manipulation  language,  information  con¬ 
tained  in  the  DSSA  Formalized  Object  Base  can  be  transformed  in  three  important 
ways.  First,  the  software  component  specifications  can  be  transformed  into  Ada  pro¬ 
grams,  via  correctness  (behavior)  preserving  formal  transformations.  The  Develop 
Ada  Components  box  in  figure  5.1  represents  this  transformation  system,  with  the 
Ada  Component  Library  being  the  results  of  such  a  system.  Another  important 
transformation  that  can  occur  is  the  composition  of  various  Ada  components  into 
an  Ada  application  system.  By  specifying  desired  behavioral  properties  of  the  ap¬ 
plication  system,  the  structural  and  behavioral  information  in  the  object  base  can 
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USER  INTERFACE: 


Object  Bam 
ManipulAtion 
Language 


Develop  Architectural  Component 


Develop  Application  Using  Components 


AppMoalion 

Syetem 


Figure  5.1.  General  Configuration  for  Formalizing  a  DSSA 

be  used  to  determine  the  Ada  components  necessary  to  construct  the  desired  appli¬ 
cation  system.  These  components  can  then  be  placed  together  via  a  driver  program 
to  form  the  application  system.  This  second  transformation  system  is  represented 
by  the  Component  Composition  Rules  box  in  figure  5.1.  The  final  transform  ition 
system  of  interest  is  the  visualization  of  the  DSSA  Formalized  Object  Base.  This 
transformation  constructs  graph-based  diagrams  from  the  object  base  information 
using  the  techniques  developed  in  Chapters  III  and  IV. 


5.3  Domain  Modeling  with  Visualization 

The  Domain  Model  and  Object  Specification  Language  are  essential  elements 
in  the  process  of  formalizing  a  DSSA.  Time  constraints  prevent  current  research 
efforts  from  completely  developing  the  Domain  Model;  however,  a  methodology  for 
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developing  this  Domain  Model  is  provided.  Additionally,  the  visualization  technology 
developed  previously  is  shown  to  be  applicable  towards  enhancing  the  Object  Spec¬ 
ification  Language  required  for  the  proposed  Domain  Model.  This  section  discusses 
the  necessary  steps  towards  building  a  useful  Domain  Specific  Modeling  System.  The 
following  three  main  tasks  must  be  accomplished; 

1.  Construct  a  Domain  Model  and  Language. 

2.  Implement  the  Domain  Model. 

3.  Develop  the  Visual  Transformation  System. 

5.3.1  Domain  Model  Construction  Before  a  Domain  Specific  Modeling  Sys¬ 
tem  can  be  constructed,  a  Domain  Model  and  Object  Specification  Language  must 
be  developed.  Two  approaches  are  offered: 

1.  Develop  the  Domain  Model  and  Object  Specification  Language,  from  the  ground 
up,  specifically  for  the  needs  of  the  desired  Domain  Specific  Modeling  System. 

2.  Develop  the  Domain  Model  from  an  existing  Object  Specification  Language, 
adapting  the  existing  language  as  necessary  to  meet  the  requirements  of  the 
desired  Domain  Specific  Modeling  System. 

Both  of  the  above  approaches  have  merit,  and  each  has  its  shortcomings.  A  short 
discussion  of  each  approach  follows. 

Development  of  a  Domain  Model  and  Language  specifically  for  the  needs  of  the 
desired  Domain  Specific  Modeling  System  has  the  advantage  of  being  constructed  to 
meet  specific  features  and  requirements  of  the  system.  For  example,  software  object  s 
could  be  modeled  with  specific  attributes  to  reflect  structural  and  behavioral  prop¬ 
erties  of  the  object.  The  development  of  the  Domain  Model  for  such  a  system  couhl 
most  likely  be  accomplished  without  too  much  difficultly;  however,  the  development 
of  a  grammar  for  the  Object  Specification  Language,  which  supports  the  developed 
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Domain  Model,  is  not  an  easy  task.  An  Object  Specification  Language  is  essential 
to  the  Domain  Specific  Software  Architecture  model  presented  above;  making  the 
choice  of  this  approach  extremely  risky. 

An  alternative  to  building  the  Domain  Model  and  Language  from  the  ground 
up,  is  to  construct  a  Domain  Model  based  upon  an  existing  Object  Description 
Language.  The  main  advantage  to  this  approach  is  the  significant  reduction  in  de¬ 
velopment  time  and  risk.  The  primary  disadvantage  is  that  desired  features  of  the 
Domain  Specific  Modeling  System  may  need  to  be  defined  in  an  awkward  manner 
or  possibly  even  eliminated.  As  long  as  an  existing  language  can  be  found  which 
adequately  describes  both  the  software  components  within  the  Domain  Specific  Soft¬ 
ware  Architecture  and  the  interrelationship  between  components  then  the  reduced 
development  time  and  risk  makes  this  the  recommended  option.  A  language  which 
potentially  meets  the  above  requirements  is  the  Requirements  Modeling  Language 
(RML)  developed  and  specified  in  (12). 

Given  that  an  existing  Object  Definition  Language,  like  RML,  has  been  de¬ 
termined  to  meet  requirements  of  the  Domain  Specific  Modeling  System,  then  four 
things  need  to  be  defined  (17:4-1): 

1.  Define  what  the  abstract  syntax  trees  will  look  like. 

2.  Define  object  classes  for  each  type  of  node  in  the  abstract  syntax  trees. 

3.  Define  attributes  that  capture  the  structure  of  the  abstract  syntax  trees. 

4.  Define  attributes  for  any  annotations  that  will  be  needed. 

Once  these  items  are  defined,  the  Domain  Model  is  ready  to  be  implemented  as 
discussed  below. 

5.3.2  Domain  Model  Implementation  The  Dialect^^  subsystem  of  the  Refine 
specification  environment  provides  an  excellent  means  for  implementing  the  Domain 
Model  (17:4-1  -  5-28).  The  nodes  of  the  abstract  syntax  tree  definitions  developed 
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for  the  Domain  Model  are  represented  in  Refine  as  object  classes;  whereas  the  tree 
structure  and  annotations  are  represented  as  object  attributes.  Each  object  class 
defined  in  step  2  above,  is  converted  to  a  Refine  definition  by  declaring  the  class 
as  a  subtype  of  either  the  Refine  predefined  super  class  (user-object)  or  as  a  sub- 
type  of  a  previously  defined  class  (17:4-3,  4-4).  Next  the  attributes  are  declared. 
Each  attribute  represents  an  arc  in  the  abstract  syntax  tree.  These  attributes  are 
used  in  production  definitions,  discussed  later.  To  complete  the  implementation  of 
the  Domain  Model,  the  abstract  syntax  tree  attributes  must  be  distinguished  from 
the  annotation  attributes.  This  is  done  through  the  use  of  the  Refine  “define-tree- 
attributes”  function  (17:4-5). 

The  Domain  model  describes  the  semantics  of  the  Object  Specification  Lan¬ 
guage  and  forms  a  basis  from  which  a  language  grammar  can  be  defined.  The  Dialect 
subsystem  is  also  used  for  describing  grammar  productions,  which  are  written  using 
an  extended  Backus  Naur  Form  (BNF),  described  in  (17.5-1  -  5-28).  By  using  at¬ 
tribute  names,  defined  in  the  Domain  Model,  as  building  blocks  within  the  grammar 
productions,  Dialect  is  able  to  automatically  construct  abstract  syntax  tree  repre¬ 
sentations  of  the  Object  Specification  Language  in  the  Refine  object  base.  This 
feature  of  Dialect  allows  the  user  to  specify  only  the  surface  syntax,  and  Dialect 
generates  most,  if  not  all,  of  the  necessary  semantic  routines,  typically  associated 
with  a  compiler. 

5.3.3  Visualizing  the  Domain  Model  The  Object  Specification  Language  im¬ 
plemented  using  the  above  technique  can  now  be  used  to  describe  the  software  com¬ 
ponents,  including  structure  and  behavior.  As  these  descriptions  are  compiled,  they 
will  be  represented  as  abstract  syntax  trees  in  the  Refine  object  base.  The  visu¬ 
alization  development  methodology  described  in  Chapters  III  and  IV  can  then  be 
directly  applied.  First,  define  which  structures  are  of  interest  for  visualization.  Re¬ 
fine’s  pattern  matching  facilities  make  it  possible  to  recognize  a  single  node  in  the 
abstract  syntax  tree,  or  to  recognize  a  particular  abstract  syntax  structure,  consisting 
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of  several  nodes.  This  ability  to  group  nodes  together  make  it  possible  to  visualize  a 
wide  range  of  structures,  from  the  very  detailed  to  the  more  abstract.  Next,  develop 
an  icon  for  each  structure  of  interest,  and  write  Refine  rules  to  specify  the  transfor¬ 
mation  from  each  structure  to  its  associated  icon.  Because  the  Object  Specification 
Language  should  be  capable  of  specifying  components  at  various  levels  of  detail,  the 
resulting  visualization  should  also  be  capable  of  displaying  various  levels  of  detail. 

5.4  Summary 

Domain  Specific  Softw'are  Architectures  are  a  natural  methodology  for  using 
object-oriented  requirements  analysis,  specification,  and  design;  however  DSSA’s  fail 
to  provide  the  necessary  formalism  to  capture  the  software  architectures  informa¬ 
tion.  The  development  and  use  of  a  formal  Domain  Model  and  Object  Specification 
Language,  along  with  a  formal  object  base  and  manipulation  system,  provide  the 
following  capabilities  for  the  above  described  DSSA. 

1.  Software  component’s  structural  and  behavioral  characteristics  are  formally 
described. 

2.  System  users  can  easily  define  and  prototype  potential  new  components  with¬ 
out  the  overhead  of  a  full  scale  development  effort. 

3.  A  formal  method  of  selecting  and  assembling  components  is  provided  for  rapid 
development  of  Ada  application  systems. 

This  chapter  has  shown  how  a  Domain  Specific  Modeling  System  can  greatly 
enhance  a  DSSA’s  capabilities,  and  how  previously  developed  visualization  technol¬ 
ogy  can  be  included  to  make  the  Domain  Modeling  System  even  more  easy  to  use 
and  understand. 
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VI.  Conclusions,  and  Recommendations 


6. 1  Introduction 

This  research  has  been  concerned  with  three  main  objectives: 

1.  The  development  of  a  formal  graphical  specification  language  which  represents 
the  Refine  wide-spectrum  language. 

2.  The  development  and  prototype  of  a  generalized  mechanism  for  transforming 
the  Refine  wide-spectrum  specification  language  into  the  previously  defined 
graphical  specification  language. 

3.  The  extension  of  the  developed  formal  language  visualization  technology  to  any 
formal  language  which  can  be  represented  in  the  Refine  object  base.  A  Domain 
Specific  Language  used  in  a  formalized  Domain  Specific  Software  Architecture 
is  an  example  of  such  a  language. 

All  three  objectives  have  been  achieved.  Chapter  III  systematically  produces  a  for¬ 
mal  definition  for  the  Visual  Refine  graphical  specification  language.  Visual  Refine 
allows  for  the  visualization  of  a  sufficient  subset  of  the  Refine  formal  specification 
language  to  be  of  general  use.  Chapter  IV  develops  a  research  prototype  visual  trans¬ 
formation  system  which  effectively  transforms  structures  in  the  Refine  wide-spectrum 
specification  language  into  graph-based  diagrams  using  the  Visual  Refine  language 
developed  in  Chapter  III.  And  finally.  Chapter  V  provides  a  methodology  for  ex¬ 
tending  the  formal  language  visualization  technology  to  the  area  of  Domain  Specific 
Software  Architectures.  Specifically,  this  research  has  accomplished  the  following: 

•  A  formal  definition  for  the  Visual  Refine  graphical  specification  language  has 
been  developed. 
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•  The  Visual  Refine  graphical  specification  language  has  been  implemented  as  a 
set  of  formal  transformations:  each  transformation  is  encapsulated  in  a  Refine 
rule,  to  form  a  formal,  rule  based,  transformation  system, 

•  A  process  for  identifying  and  firing  applicable  Visual  Refine  rules  has  been 
developed.  This  process  facilitates  the  systematic  construction  of  Visual  Refine 
Diagrams. 

•  Several  enhancements  and  extensions  to  the  Visual  Refine  formal  transforma¬ 
tion  system  have  been  identified,  along  with  recommended  methodologies  for 
implementing  these  enhancements  and  extensions.  Extensions  and  enhance¬ 
ments  include: 

1.  extension  of  the  Visual  Refine  language  to  include  Refine  control  struc¬ 
tures,  such  as  an  if-then-else. 

2.  enhance  user  friendliness  with  an  automatic  diagram  generation  system. 

•  A  methodology  for  applying  the  newly  developed  formal  language  visualization 
technology  in  the  area  of  Domain  Specific  Software  Architectures  has  been 
developed. 

6.2  Conclusions 

Several  conclusions  can  be  made  as  a  result  of  this  research  in  Graph-Basc'd 
Visualization.  They  are; 

•  Formal  transformations  from  complex,  difficult  to  understand,  formal  spec¬ 
ifications,  to  simpler,  more  easily  understood,  graph-based  visualizations  is 
an  achievable  means  of  making  formal  specifications  a  more  widely  accepted 
method  of  software  development.  A  major  hinderance  to  the  use  of  formal 
methods  is  the  inherent  complexity  associated  with  the  formal  specification. 
Graph-Based  diagrams  offer  a  more  natural,  less  complex,  way  of  presenting 
the  complicated  information  contained  in  a  formal  specification. 
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•  The  Refine  fo'-mal  specification  environment  is  an  ideal  platform  for  building  a 
formal  graph-based  visualization  transformation  system,  such  as  Visual  Refine. 
The  visualization  technology  developed  by  this  research  depends  upon  being 
able  to  recognize  and  manipulate  abstract  syntax  tree  structures  represented 
in  an  object  base.  Refine’s  built-in  tools  for  constructing  and  manipulating 
abstract  syntax  tree  structures  are  extensive.  This  allows  the  developer  to 
concentrate  on  the  problem,  and  its  solution,  rather  than  on  the  mechanics  of 
the  development  environment. 

•  Domain  Specific  Software  Architectures  can  be  enhanced,  providing  greater 
benefits  and  more  power,  by  developing  a  formal  Domain  Model  and  Ob¬ 
ject  Specification  Language.  By  incorporating  graph-based  visualization  tech¬ 
niques,  developed  in  this  thesis,  into  the  Domain  Model  and  Object  Specifica¬ 
tion  Language,  complicated  software  and  application  structures  can  be  more 
easily  understood. 

6.3  Recommendations  for  Future  Research 

Several  areas  of  future  research  can  be  derived  from  the  research  contained  in 
this  thesis.  Listed  below  are  research  areas  which  could  be  continued  directly  from 
this  research. 

•  Visual  Refine  is  currently  uni-directional,  meaning  that  the  transformation 
goes  from  the  formal  specification  to  the  graph-based  visualization.  The  formal 
foundation  provided  by  this  research  along  with  the  powerful  graphical  input 
facilities  of  the  Intervista  subsystem  of  Refine  provide  a  natural  mechanism  for 
implementing  the  inverse  transformations. 

•  Enhance  the  Visual  Refine  Transformation  System  to  include  non-icon  produc¬ 
ing  transformations.  This  would  give  Visual  Refine  the  capability  to  recognize, 
and  process,  abstract  syntax  tree  structures  that  do  not  result  in  the  generation 
of  an  icon,  but  rather  serve  only  to  link  other  abstract  syntax  tree  structures 
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together;  the  ‘rule-impl-op’  is  one  such  structure  which  could  be  processed  to 
generate  the  control  links  necessary  to  describe  the  Refine  transform  construct. 

•  Further  develop  the  Visual  Refine  rules,  to  provide  an  automated  diagram  gen¬ 
eration  system.  This  requires  a  careful  analysis  of  each  rule  to  determine  how 
it  should  effect  the  object  base  in  pieparation  for  the  next  rule  firing.  Addi¬ 
tionally,  each  rule  needs  to  be  evaluated  as  to  its  relationship  with  other  rules 
to  determine  the  sequencing  used  by  the  methodology  described  in  section  4.6. 

•  Develop  methodologies  and  algorithms  for  the  automatic  layout  of  icons,  and 
the  automatic  routing  of  links,  in  support  of  the  visualization  technologies 
developed  in  this  thesis. 

•  Investigate  methods  of  linking  the  various  graph-based  diagrams  together  in  a 
hierarchical  manner.  This  type  of  methodology  would  provide  the  capability  to 
construct  a  formal  specification  from  a  set  of  diagrams,  beginning  with  a  high 
level  concept  diagram  which  can  then  be  further  refined  in  much  the  same  way 
as  Data  Flow  Diagrams  are  constructed.  Another  aspect  of  this  methodology 
is  the  capability  to  automatically  generate  a  visualization  of  an  entire  system 
by  constructing  the  graph  hierarchy  from  the  implicit  hierarchy  of  the  formal 
specification. 

•  A  motivating  factor  for  this  thesis  was  to  use  visual  technologies  to  allow  greater 
understanding  of  formal  specifications;  resulting  in  greater  acceptance  of  for¬ 
mal  specifications  as  a  software  engineering  tool.  Furthermore,  a  substantial 
increase  in  overall  life  cycle  productivity,  and  thus  a  substantial  decrease  in 
overall  life  cycle  costs,  is  expected  as  a  result  of  using  Balzer’s  Automation- 
Based  life  cycle  model.  Although  it  is  believed  that  the  visual  technologies 
developed  in  this  thesis  have  indeed  made  formal  specifications  easier  to  un¬ 
derstand,  research  aimed  at  quantifying  improved  understanding,  increased  life 
cycle  productivity,  and  decreased  life  cycle  costs,  is  needed. 
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•  Chapter  V  only  lays  the  very  basics  of  a  foundation  for  enhancing  Domain 
Specific  Software  Architectures.  This  bas'c  methocology  needs  to  be  developed 
into  a  prototype  system  which  verifies  the  benefits  and  potential  of  a  formal 
Domain  Model.  This  area  of  research  is  wide  open  and  could  include  several 
independent  but  related  research  topics  to  include: 

1.  the  construction  of  a  formal  Domain  Model  based  upon  the  Requirements 
Modeling  Language  in  support  of  DSSA’s  in  general. 

2.  the  construction  of  a  formal  Domain  Model  and  Object  Description  Lan¬ 
guage  which  supports  the  specific  needs  of  a  formalized  DSSA,  and 

3.  the  construction  of  an  overall  prototype  formal  based  Domain  Modeling 
System.  This  overall  prototype  system  would  need  to  be  able  to  support 
the  formal  development  of  software  components,  the  manipulation  of  soft¬ 
ware  components  within  the  object  base,  and  the  assembly  of  components 
into  a  software  application. 

6.4  Final  Remarks 

Software  Engineering  can  not,  and  should  not,  change  overnight;  however  Soft¬ 
ware  Engineering  must  change.  The  current  methodologies,  even  with  the  advent 
of  computer  aided  software  engineering  (CASE)  tools,  can  only  offer  small  improve¬ 
ments  to  the  problems  addressed  in  Chapter  I  of  this  thesis.  Formal  methods  of 
software  engineering,  on  the  other  hand,  potentially  offer  order  of  magnitude  im¬ 
provements  to  the  software  industry.  Improvements  which  can  have  as  profound  an 
effect  on  the  field  of  software  engineering  as  the  invention  of  the  numeral  zero  and 
in-place  notation  had  on  the  field  of  mathematics  (14).  Casual  disregard  for  for¬ 
mal  methodologies  will  make  even  the  most  respected  software  development  gurus 
antiquated  relics  in  the  not  to  distant  future. 
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Appendix  A.  Refine^’^^  Primitive  Operations  Categorized  by 

Operand  Data  Type 


The  following  information  is  directly  obtained  from  (15:appendix  D)  and  is  in¬ 
cluded  to  aid  in  the  readers  understanding  of  how  the  Visual  Refine  formal  graphical 
specification  language  was  developed. 


This  appendix  contains  Refine’s  primitive  operations  categorized  by  the 
operand  types  of  the  operations. 

•  Numbers 

-  Addition 

-  Subtraction 

-  Multiplication 

-  Division 

-  Integer  Division 

-  Integer  Remainder  (Modulo) 

-  Integer  to  Real  Coercion 

-  Equality 

-  Creator  Than 

-  Greater  Than  or  Equal  To 

-  Less  Than 

-  Less  Than  or  Equal  To 

•  Chvracters 

-  Equality 

—  Greater  Than 
—  Greater  Than  or  Equal  To 
—  Less  Than 

-  Less  Than  or  Equal  To 

•  Booleans 

-  Negation 

-  Conjunction 

-  Disjunction 
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—  Implication 

-  Ordered  Conjunction 

-  Ordered  Disjunction 

-  Universal  Quantification 

-  Existential  Quantification 

-  Nondeterministic  Choice 

-  Equality 

•  Symbols 

-  Symbol  To  String  Coercion 

-  Equality 

•  Sets 

-  Size 

-  Arbitrary  Element 

-  Element  Addition 

-  Element  Deletion 

-  Union 

-  Intersection 

-  Set  Difference 

-  Filter  by  a  Predicate 

-  Reduction  by  an  Operation 

-  Set  to  Sequence  Coercion 

-  Empty 

—  Membership 

-  Subset 

-  Equality 

•  Sequences 

-  Size 

-  n-th  Element 

-  First  Element 

-  Last  Element 
—  Subsequence 

-  Following  Subsequence 

-  Assignment  of  n-th  Element 
—  Insertion  as  n-th  Element 

—  Append  an  Element 
—  Prepend  an  Element 
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—  Delete  the  n-th  Element 

-  Reverse 

-  Image  Under  a  Map 

-  Domain 

-  Range 

—  Concatenate 
—  Filter  by  a  Predicate 

-  Reduction  by  an  Operation 

-  Sequence  to  Set  Coercion 

-  Sequence  to  Map  Coercion 

-  Empty 

-  Membership 

-  Equality 

•  Strings 

-  Greater  Than 

—  Greater  Than  or  Equal  To 
—  Less  Than 

-  Less  Than  or  Equal  To 

•  Tuples 

-  Field  Retrieval 

-  Field  Assignment 

-  Equality 

•  Maps 

-  Size 

-  Filter  by  a  Map 
—  Image 

-  Domain 

-  Range 

-  Closure 

-  Composition 

-  Inverse 

-  Map  to  Binary  Relation  Coercion 

-  Empty 

-  Equality 

•  Binary  Relations 

-  Image 
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-  Domain 

-  Range 

-  Closure 

—  Composition 
—  Transitive  Closure 
•  Objects 

-  Creation 

—  Destruction 
—  Attribute  Assignment 

-  Attribute  Retrieval 
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Appendix  B.  Refine^^  Primitive  Operations  Categorized  by 

Operation  Characteristics 


The  following  information  is  directly  obtained  from  (15:appendix  E)  and  is  in¬ 
cluded  to  aid  in  the  readers  understanding  of  how  the  Visual  Refine  formal  graphical 
specification  language  was  developed. 


This  appendix  contains  a  listing  of  Refine's  primitive  operations  cate¬ 
gorized  by  conceptual  similarities.  If  multiple  primitive  operations  are 
grouped  together  under  a  single  operation  heading,  a  listing  of  the  pos¬ 
sible  operand  types  follows  the  operation  heading. 

•  Simple  Assignment 

—  Numbers 

-  Characters 

-  Booleans 

-  Symbols 

-  Sets 

—  Sequences 

-  Strings 

-  Tuples 
—  Maps 

-  Binary  Relations 

-  Objects 

•  Addition 

—  Numbers 

—  Sets  (Element  Addition) 

—  Sequences  (Concatenation) 

•  Subtraction 

-  Numbers 

—  Sets  (Element  Deletion) 

-  Sets  (Set  Difference) 

•  Multiplication 
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•  Division 

•  Integer  Division 

•  Integer  Remainder  (Modulo) 

•  Integer  to  Real  Coercion 

•  Equality 

-  Numbers 

-  Characters 

-  Booleans 

-  Symbols 

-  Sets 

-  Sequences 

-  Tuples 

-  Maps 

•  Greater  Than 

-  Numbers 
—  Characters 
—  Strings 

•  Greater  Than  or  Equal  To 

-  Numbers 

-  Characters 
—  Strings 

•  Less  Than 

-  Numbers 

-  Characters 
—  Strings 

•  Less  Than  or  Equal  To 

—  Numbers 

-  Characters 

-  Strings 

•  Symbol  to  String  Coercion 

•  Negation 

•  Conjunction 

•  Ordered  Conjunction 

•  Disjunction 
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•  Ordered  Disjunction 

•  Implication 

•  Universal  Quantification 

•  Existential  Quantification 

•  Size 

-  Sets 

-  Sequences 

-  Maps 

•  Arbitrary  Element 

—  Booleans 

-  Sets 

•  Union 

•  Intersection 

•  Filter  by  a  Predicate 

-  Sets 

-  Sequences 

-  Maps 

•  Set  to  Sequence  Coercion 

•  Subset  Test 

•  Empty  Test 

—  Sets 

-  Sequences 

-  Maps 

•  Membership 

•  n-th  Element 

•  First  Element 

•  Last  Element 

•  Subsequence 

•  Rest  of  Sequence 

•  Assign  n-th  Element 

•  Insert  at  n-th  Position 

•  Append  Element 

•  Prepend  Element 
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•  Delete  n-th  Element 

•  Reverse 

•  Image 

-  Sequences 

-  Maps 

—  Binary  Relations 
t  Domain 

—  Sequences 

-  Maps 

-  Binary  Relations 

•  Range 

-  Sequences 
—  Maps 

-  Binary  Relations 

•  Sequence  to  Set  Coercion 

•  Map  Coercion 

-  Sequences 

-  Binary  Relations 

•  Field  Retrieval 

—  Tuples 

-  Objects 

•  Field  Assignment 

—  Tuples 

-  Objects 

•  Closure 

-  Maps 

—  Binary  Relations 

•  Composition 

-  Maps 

-  Binary  Relations 

•  Inverse 

•  Map  to  Binary  Relation  Coercion 

•  Transitive  Coercion 
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Appendix  C.  Place's  Graphical  Notation 


This  appendix  contains  a  complete  listing  of  the  graphical  notation  developed 
by  Place  in  (15:5-16  -  5-33).  The  icons  are  organized  in  the  same  manner  that 
place  developed  them  and  generally  follow  Places  decomposition  of  the  Refine  wide- 
spectrum  language  (15: Appendix  D)  found  in  Appendix  A.  Each  of  the  following 
figures  corresponds  to  a  similar  figure  found  in  Places  work  (15). 


I  +  ^  i  * 

Addition  Subtraction  Multiplication 
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Integer 
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Real 

Coercion 

Division 

Remainder 

Equality 


Greater  Less  Greater  Than  Less  Than 

or  Equal  to  or  Equal  to 


Figure  C.l.  Mathematical  Operations 
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Simple 

Assignment 


Figure  C.2.  Simple  Assignment  Operator 
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Ordered 
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Figure  C.3.  Boolean  Operations 


C  2 


Union 


(Q)  (c)  (e) 

Intersection  Subset  Membership 


Set  Addition  or  Set  Difference  or 
Element  Addition  Element  Removal 


SEQ, 

Sequence 

Coercion 


Filter  Size 


^0?) 

\  / 

Empty  Test 


Arbitrary 

Element 


Figure  C.4.  Set  Operations 
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1-st  Element  n-th  Element  Last  Element  Subsequence  Concatenate 


(t)  {^)  (0)  t>SEf\  f>MAP) 

Prepend  Insert  Append  Reverse  Set  Map 
Element  n-th  Element  Element  Coercion  Coercion 


(|dom| 

Domain 


RNG  ' 

\ _ _ 

Range 


Filter 


/ 

Assisi 

n-th  Element 


Empty  Test 


Membership 


Figure  C.5.  Sequence  Operations 
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Figure  C.6.  Tuple  Operations 
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Figure  C.7.  Map  and  Binary  Relations  Operations 
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Figure  C.8.  Miscellaneous  Other  Operations 
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Place  also  includes  a  notation  for  distinguishing  between  an  object  and  other 
data.  Figure  C.9  illustrates  this  distinction. 


Object  Data 


Figure  C.9.  Data  Type  Notation 
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Appendix  D.  Refine  Abstract  Syntax 


This  appendix  contains  a  listing  of  abstract  syntax  representations  of  the  Refine 
wide-spectrum  specification  language.  Each  icon  developed  by  Place  (15:5-16  -  5- 
33)  and  listed  in  Appendix  C,  is  listed  here  in  the  internal  Refine  abstract  syntax. 
The  organization  of  this  Appendix  is  identical  to  Appendix  C,  so  that  matching 
the  abstract  syntax  to  the  graphical  icon  can  be  done  easily.  Each  of  the  following 
figures  corresponds  directly  to  a  figure  found  in  Appendix  C. 
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Figure  D.l.  Mathematical  Operations 
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Figure  D.2.  Simple  Assignment  Operator 
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Figure  D.3.  Boolean  Operations 
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.  Set  Operations 
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Figure  D.5.  Sequence  Operations 
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Figure  D.6.  Tuple  Operations 
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Figure  D.7.  Map  and  Binary  Relations  Operations 
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The  Start,  Stop,  and  Display  symbols  within  Visual  Refine  are  special  symbols 
and  have  no  abstract  syntax  structure  within  Refine.  There  is  an  alternate  “from, 
to,  by”  enumeration  abstract  syntax  structure  that  is  not  shown.  This  alternative 
structure  can  be  rewritten  to  create  the  “baseset”  structure  shown,  and  therefore 
the  “baseset”  enumeration  structure  has  been  chosen  to  represent  enumeration. 


( OBJECT  DESTRUCTION )  ( ENUMERATION ) 


optrMion 

RHor  -  Ape 

r '  • 

erase  Object  object 


enumeration-op 


Baseset 


Consumer 


r 

setorseq 


Statement 


Figure  D.8.  Miscellaneous  Other  Operations 

The  data  notation  used  by  Place  (15:5-33)  is  not  an  operation,  and  therefore 
does  hot  have  a  specific  abstract  syntax  structure  within  Refine.  The  data  type  icons 
will  be  used  to  represent  binding-ref  attributes  of  objects. 
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Appendix  E.  Visual  Refine 


This  appendix  defines  the  Visual  Refine  graphical  specification  language.  The 
appendix  has  three  sections.  The  first  section  contains  all  icons  that  were  carried 
over  from  Place’s  notation  (Appendix  C)  with  only  the  input  and  output  ports 
formally  defined.  The  second  section  contains  all  icons  that  were  ovei.oaded  in 
Place’s  notation  with  the  combined  Refine  abstract  syntax  tree  structure  defined. 
\nd  the  last  section  contains  the  icons  which  have  been  developed  as  a  result  of 
formalizing  Place’s  notation.  Also  contained  in  the  last  section  is  a  list  of  icons 
which  have  been  deemed  unnecessary  or  ambiguous  to  the  Visual  Refine  specification 
language. 

The  purpose  of  this  research  is  to  show  the  applicability  of  visual  technolo¬ 
gies  toward  making  formal  specifications  easier  to  understand.  This  research  is  not 
necessarily  concerned  with  the  implementation  issues  associated  with  constructing 
graphical  icons.  For  this  reason,  some  icons  are  annotated  with  a  word  contained  in 
quotes.  This  word  represents  a  simpler  textual  icon,  created  for  the  Visual  Refin« 
prototype  system,  developed  as  part  of  this  research.  Textual  icons  are  more  easily 
implemented,  as  compared  to  the  detailed  graphical  icons  defined  for  many  of  the 
Visual  Refine  constructs.  Therefore,  the  simpler  textual  icons  have  been  used;  the 
textual  annotation  is  included  in  the  definition  to  avoid  confusion.  Visual  Refine 
icon  definitions  which  do  not  have  the  textual  annotation  have  been  prototyped  as 
defined. 
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E.l  Formalized  Icons  Carried  Forward 
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E.2  Overloaded  Icons 


r  • 

any  lypt  SHnaiypa 
KAigl 


j. 


'MEMBER* 


<=> 


■lytypa  tat|atqu*)wt 


att|mip|tiqMnM 


•FILTER* 
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The  following  iwo  syint>ola  must  De  evaluated  m  context  wift  other  stucturea  They  are  included  here  lor  completeness 
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E.3  Newly  Developed  Icons 


KinMIon  ninw  pwrivlv  IM 

Where  'NAME'  is  the  function  narrte 


•MAKE' 

/ 

A  String 


<=> 


I  l-sltflg 
Mug 


Where  '9999'  is  the  integer 
represented  by  l-integer. 


Where  ‘AStnng’  is  the  string 
represented  by  l-string 


The  following  icons  have  not  been  deemed  necessary  to  the  Visual  Refine  spec¬ 
ification  language: 
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•  Assign  Nth  Element  (sequence  operation) 

•  Field  Assignment  (tuple  operation) 

Both  of  the  above  items  are  just  instances  of  the  simple  assignment  operation,  and 
therefore  are  redundant.  Including  these  items  will  also  introduce  ambiguity  into 
the  Visual  Refine  specification  language. 
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Appendix  F.  Visual  Refine  Implementation 


This  appendix  contains  the  Refine  formal  specification  for  the  Visual  Refine 
graphical  specification  language.  Each  Icon  defined  in  appendix  E  is  implemented 
using  a  Refine  ‘rule’  (19:3-167).  This  appendix  is  divided  into  six  sections.  The  first 
section  contains  the  Visual  Refine  environment  definition,  along  with  some  internal 
utility  functions,  and  the  Visual  Refine  startup  rule.  Each  of  the  next  five  sections 
corrisponds  directly  to  sections,  of  the  same  name,  in  chapter  IV. 


F.l  Visual  Refine  Environment 


! !  in-packag«("RU") 

!!  in-graBBar( ’user) 

% - Visual  Rsflns  Envlroimsnt  Dsfinltions - 

var  DV-LL-X:  intsgsr  >  10 

var  DV-LL-Y:  intsgsr  «  40 

var  OV-Width:  intsgsr  =  5S0 

var  DV-Hsight:  intsgsr  *  680 

var  DV:  ri: ‘.diagraa-sindos  «  undsfinsd 
var  DS:  ri:  idiagrsa-surfacs  *  undsfinsd 

var  VR-Icon:  aapC  Objsct,  ri::icon  )  ^  {||} 

var  VR-Icon-for-Objsct:  aapC  Objsct,  ri::icon  )  »  {||} 

var  VR-Objsct-for-Icon:  aapC  ri::icon,  Objsct  )  >  {||} 

fora  Dsfins-Functional-Convsrsss 

dsf ins-f nn-convsrsss (  ’ VR-Icon-f or-Objsct , 

'VR-Objsct-for-Icon,  trus  ) 

var  binding-List :  sst(  ri::icon  )  *  {} 

var  Stop-Icon:  ri::icon  *  aaks-objsctC  ’ri::icon  ) 

X  -  Visual  Rsfins  Utility  Functions  - 

function  In-Binding-List? (  L  :  soq(  string  }  )  :  boolsan  = 
lst(  in-list:  boolsan  *  falss  ) 

(  snuasrats  bl:  ri::icon  ovsr  binding-list  do 
if(  ri::labsl(  bl  )  *  L  )  thsn 
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in-litt  <-  tru* 


); 

in-list 

function  VR-Icon-for-Objsct?(  X:  Objsct  )  :  boolsan  « 
if(  VR-Icon-for-Objsct(  I  )  ^  undsfinsd  )  thsn 
falss 

slss 

trus 


function  VR-Icon?(  X:  Objsct  )  :  boolsan  = 
if(  VR-Icon(  X  )  -  undsfinsd  )  thsn 

falss 

slss 

trus 


function  6st-BL-Icon(  L:  ssq(  string  )  )  :  ri::icon  = 
lst(  found-icon;  ri::icon  «  nil  ) 

(  snunsrats  bl:  ri:;icon  ovsr  binding-list  do 
if(  ri::labsl(  bl  )  «  L  )  thsn 
found-icon  <-  bl 


); 

found-icon 


function  VR-Maks-String(  I:  intsgsr  )  :  string  - 
lst(  int-string:  string  >  C], 

Los-Digit:  intsgsr  *  I, 

Othsr-Oigits :  intsgsr  >  I 

) 

(  if(  I  0  }  thsn 

shilsC  Othsr-Oigits  o  )  do 

Low-Digit  <-  Othsr-Digits  nod  10; 
Othsr-Digits  <-  Othsr-Oigits  div  10; 

(  if(  Low-Digit  s  0  )  thsn 

int-string  <-  prspsndC  int-string,  #\0  ) 
slssif(  Low-Digit  =  1  )  thsn 

int-string  <-  prspsndC  int-string,  #\1  ) 
slssifC  Low-Digit  =  2  )  thsn 

int-string  <-  prspsndC  int-string,  «\2  } 
slssifC  Low-Digit  «  3  )  thsn 

int-string  <-  prspsndC  int-string,  #\3  ) 
slssifC  Low-Digit  «  4  )  thsn 

int-string  <-  prspsndC  int-string,  #\4  ) 
slssifC  Low-Digit  «  6  )  thsn 

int-string  <-  prspsndC  int-string,  #\5  ) 
slssifC  Low-Digit  *  6  )  thsn 

int-string  <-  prspsndC  int-string,  #\6  ) 
slssifC  Low-Digit  *  7  )  thsn 
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int-itring  <-  pr«p«nd(  int-itring,  #\7  ) 
Low-Digit  B  8  )  thwn 
int-string  <-  pr«pwnd(  int-string,  #\8  ) 
tltwifC  Low-Digit  =  9  )  than 

int-string  <-  prspsndC  int-string,  #\9  ) 

) 

slss 

int-string  <-  prspsnd(  int-string,  #\0  ) 

): 

int-string 


% - Visual  Rsfins  Startup - 

ruls  Visual-RslinaO 
trus 

— > 

binding-list  >  {}  k 

DS  B  ■aks-objact(  'ri: rdiagraa-auxiaca  )  k 

DU  B  aaku-objactC  'ri: idiagraa-window  )  k 
ri::surlacs-viswsd(  DU  )  b  ds  k 

ri : : window-rsgion  (  DU  )  * 

ri: :aaks-r«gion(  DU-LL-X,  DU-LL-Y, 

DU-Uidth,  DU-Hsight  )  k 


ri::window-titls(  DU  )  >  »visual  Rsfine”  t 
ri: :window-icon-titls(  DU  )  *  "V-Rsfins"  k 
ri: :hoas-surlacs(  Stop-Icon  )  »  ds  t 
ri:  :icon-t]rps(  Stop-Icon  )  «  *ri::sllip8s  k 
ri: :hsight-width-ratio(  Stop-Icon  )  «  0.5  k 
ri::labsl(  Stop-Icon  )  »  [  "STOP"  ]  k 


ri: :clip-icon-labsl?(  Stop-Icon  )  >  falsa  k 
ri: :position(  Stop-Icon  )  b 
ri: :Baka-point( 

DU-LL-X  +  (DU-Uidth  -  66  ) , 
DU-LL-Y  )  k 

ri: :azposa-window(  DU  ) 


% - Visual  Ralina  Control  Oparations - 

rula  VR-Rnla-0p(  X:  objact  ) 
ra::rala-op(  X  ) 

“> 

ri::icon(  a  )  ft  ri: :hoBa-8urfaca(  a  )  *  ds  ft 

ri: :icon-typa(  a  }  b  'ri::allipsa  ft 
ri: :haight-width-ratio(  a  )  =  o.S  ft 
ri::labal(  a  )  b  [  "START"  ]  ft 

ri: :clip-icon-labal?(  a  )  b  falsa  ft 
ri: :position(  a  )  b 
ri: :Baka-point( 

DU-LL-X  +  36, 

DU-LL-Y  +  (DU-Haight  -  100))  ft 
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VR-Obj«ct-lor-Icon(  a  )  s  x 
VR-Icon-lor-Objact(  X  )  *  a 


t 


ml*  VR-VFunction-Op(  X:  objact  ) 
ra: :vlunct ion-op (  X  ) 

— > 

ri::icon(  a  )  t  ri: rhoaa-aurfacaC  a  )  «  DS  * 

ri: ;icon-typa(  a  )  =  ’ri::allipaa  k 
ri: :haight -width-rat lo(  a  )  »  0.6  k 
ri::labal(  a  )  =  [  "START"  ]  * 

ri: ;clip-icon-labal?(  a  )  =  falsa  k 
ri: :position(  a  )  » 
ri: :Baka-point( 

DW-LL-X  ♦  36, 

Dtf-LL-Y  +  (DW-Haight  -  100))  k 
VR-Objact-lor-Icon(  a  )  =  X  k 

VR-Icon-for-Objact(  X  )  =  a 


F.2  Top  Level  Icons 


M  in-packaga("RU") 

! !  in-granar(  ’usar) 


rula  VR-Assignaant-OpC  X:  objact  ) 
ra: :assignBant-op(  X  ) 

— > 

ri::icon(  a  )  A  ri: :hoBa-sttrfaca(  a  )  ^  d5  k 

ri:  :icon-t]rpa(  a  )  >  'ri::allip8a  t 
ri: :haight -width-rat io(  a  )  ^  i.o  ft 
ri::labal(  a  )  >  [  "ASSIGI"  ]  ft 
ri: :clip-icon-labal?(  a  )  >  falsa  ft 
VR-Objact-for-Icon(  a  )  =  X 


mla  VR-Ennaarata-Op(  X:  objact  ) 
ra: :animarata-op(  X  ) 

— > 

ri::icon(  a  )  ft  ri: :hoBa-siirfaca(  a  )  =  OS  ft 

ri: :icon-t7pa(  a  )  «  'ri::allipoa  ft 
ri: :haight-width-ratio(  a  )  *  1.0  ft 
ri::labal(  a  )  *  [  "ElUNERATE"  ]  ft 
ri: :clip-icon-labal?(  a  )  «  falsa  ft 
VR-0bjact-for-Icon(  a  )  »  X  ft 

VR-Icon-for-Objact(  X  )  »  a 
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F.3  Embedded  Icons 


>•  in-packagaC'RU") 

! !  in-graaaarC  *us«r) 


rula  VR-Lit«ral-Iiit«g«r-Op(  X:  obj«ct  ) 
r«: :lit«ral-int«g«r-Op(  X  )  R 
VR-Icon-lor-Obj«ct?(  r«:  :p«r*nt-«xpr(  X  )  ) 

— > 

ri::icon(  a  )  R  ri:  :hoM-sttrfac«(  a  )  s  dS  R 

ri: :icon-typa(  a  )  >  'ri::tazt  R 

ri::labal(  a  )  > 

C  VR-Naka-String( 

ra: :l-intagar(  X  )  ) 

]  R 

ri:  :elip-icon-labal?(  a  )  >  lalaa  R 
VR-Objact-for-Icon(  a  )  «  X  R 

ri::link(  b  }  R  ri:  :hoaa-stirfaca(  b  )  »  DS  R 

ri::aoiirca(  b  )  ^  «  t 

ri::targat(  b  )  = 

VR-Icon-lor-Ob j  act ( 

ra: :parant-azpr(  X  ))  R 

ri: :djnaaic?(b)  «  trua 


rula  VR-Litaral-String-Op(  X:  objact  ) 
ra:  :litaral-atrixig-Op(  X  }  R 
VR-Icon-lor-Objact?(  ra: :paraiit-azpr(  X  )  ) 

“> 

ri::icoB(  a  )  R  ri: :hoBa-attrfaca(  a  )  «  DS  R 

ri: :icon-t7pa(  a  }  -  'ri::taxt  R 
ri::labal(  a  )  « 

C  ra: :l-string(  X  )  ]  R 

ri: :clip-icon-labal?(  a  }  b  falsa  R 
ri: :clip-icon-labal?(  a  )  »  falsa  R 
VR”Objaet-for-Icon(  a  )  =  X  R 

ri::liiik(  b  )  R  ri:  :hoaa-surfaca(  b  )  >  DS  R 

ri: :sourca(  b  )  «  a  R 

ri::targat(  b  )  = 

VR-Icon-f or-Ob j  act ( 

ra:  :paraiit-axpr(  X  ))  R 

ri: :dynaBic?(b)  *  trua 


rula  VR-SatForBar-Op(  X:  objact  ) 
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(  r«:  :s«tfora«r-op(  X  )  or  ro:  :lit«rals«t-op(  X  )  )  k 
VR-Icoii-lor-Obj«ct?(  r«:  :par«nt-«xpr(  X  )  ) 

•> 

rl::icon(  a  )  k  ri: :hoa«-farfac«(  a  )  =  OS  k 

ri:  :icon-typ«(  a  )  =  'ri::allips«  k 
ri: :h«ight-«idth-ratio(  a  )  »  i.o  k 
ri::lab*l(  a  )  *  [  "SET"  ]  k 

ri: :clip-icon-lab«l?(  a  )  =  lalst  k 

VR-Obj«ct-for-Icon(  a  )  =  X  k 

VR-Icon-for-ObjactC  X  )  =  a  k 

ri::link(  b  )  k  ri: :hoB«-tarfaca(  b  )  s  ds  k 

ri::sourc«(  b  )  =  a  k 

ri::targ«t(  b  )  * 

VR-Icon-lor-Objact( 

ra: :parant-*xpr(  X  ))  k 

ri:  :dynuiic?(b)  ^  true 


rul«  VR-Plus-0p(  X:  objact  ) 
ra::plua-op(  X  )  k 

VR-Icon-for-Qbjact?(  ra:  :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  k  ri: :hoBa-attrfaca(  a  )  *  DS  k 

ri: licoa'tjpaC  a  )  >  *ri::allipsa  k 
ri:  :haight-«idth-ratio(  a  )  =  1.0  k 
ri:-labal(  a  )  =  [  ]  k 

ri: :clip-icon-labal?(  a  )  «  falsa  k 

VR-Objact-for-Icon(  a  )  »  X  k 

VR-lcon-lor-Objact(  X  )  >  a  k 

ri::liiik(  b  )  k  ri:  :hoBa-sttrfaca(  b  }  :=  DS  k 

ri::soiirca(  b  )  «  a  k 

ri::targat(  b  )  > 

VR-Icon-f  or-Ob  j  act  ( 

ra: :parant-axpr(  X  ))  k 

ri:  :d]maBic?(b)  *  tma 


rula  VR-Niii'is-Op(  X:  objact  } 
ra:  :Binv.s-op(  X  }  k 

VR-Icon-for-Objact?(  ra:  :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  k  ri: :hoBa-sttrfaca(  a  )  s  DS 

ri:  :icon-typa(  a  )  =  *ri::allipsa 
ri:  :haight-width-ratio(  a  )  <:  1.0 
ri::labal(  a  )  *  [  ] 

ri:  :clip-icon-labal?(  a  )  =  falsa 
VR-Objact-for-Icon(  a  )  =  X 
VR-Icon-f or-Ob j act (  X  )  =  a 
ri::link(  b  )  k  ri:  :hoBa-sarfaca(  b  )  =  DS 
ri::sottrca(  b  )  =  a 
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ri::t«rg«t(  b  )  > 

VR“Icoii-lor-Obj«ct( 

r«: : parent -*«zpr(  X  ))  k 

ri: :dynaBic?(b)  *  true 


rule  VR-Viaas-Op(  X:  object  ) 
re: :tiBe8-op(  X  )  k 

VR-Icon-lor-Object?(  re:  :parent-ezpr(  X  )  ) 

— > 

ri::icon(  a  )  k  ri:  thoae-eurfaceC  a  )  ^  DS  k 

ri: :icon-type(  a  )  =  'ri::ellipie  k 
ri: : height -«idth-ratio(  a  )  =  1.0  k 
ri::label(  a  )  =  [  ]  k 

ri: :clip-icon-labal?(  a  )  *  false  k 

VR-Object-for-Icon(  a  )  =  X  k 

VR-Icon-for-Object(  X  )  =  a  k 

ri::link(  b  )  k  ri:  :hoae-sttrface(  b  )  =  DS  k 

ri: :soarce(  b  )  s  a  k 

ri::target(  b  }  > 

VR-lcon-for-Obje  ;t( 

re: :parent-ezpr(  X  ))  k 

ri: :dynaaic?(b)  *  true 


rule  VR-Divided-By-Op(  X:  object  ) 
re:  :divided-by’'op(  X  )  k 
VR>Icon-for*-Object?(  re:  :parent-expr(  X  )  ) 

— > 

ri::icon(  a  )  k  ri:  :hoae-8urface(  a  )  *  DS  k 

ri: :icon-type(  a  )  *  'ri::ellipse  k 
ri: :height-*idth-ratio(  a  )  *  1.0  k 
ri::label(  a  )  =  [  "/"  ]  k 

ri: : clip-icon- label? (  a  }  «  false  k 

VR-Object-for-Icon(  a  )  *  X  k 

VR-Icon-for-Object(  X  )  *  a  k 

ri::link(  b  )  k  ri:  :hoae-surface(  b  )  s  ds  k 

ri: :source(  b  )  =  a  k 

ri: :target(  b  )  > 

VR-Icon-for-Object( 

re: :parant-ezpr(  X  ))  k 

ri: :dynaaic?(b)  ^  true 


rule  VR-DiY-0p(  X:  object  ) 
re::div-op(  X  }  k 

VR-Icon-for-Object?(  re:  :parent-ezpr(  X  )  ) 

— > 

ri::icon(  a  )  k  ri: :hoae-surface(  a  )  =  DS  k 

ri: :icon-type(  a  )  ^  *ri::ellipse  k 
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ri:  :h«ight-«idth-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  =  [  ”DIV"  ]  ft 

ri: :clip-icon-labal?(  a  )  =  lalsa  ft 

VR-Objtct-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::lixik(  b  )  ft  ri:  :hoBa-8urlaca(  b  )  «  DS  ft 

ri: :sottrc«(  b  )  ^  a  ft 

ri:  :targ«t(  b  )  s 

VR-Icon-lor-Ob j  act ( 

ra: :parant-axpr(  X  ))  ft 

ri: :dynaBic?(b)  &  trua 


rula  VR-Mod-Op(  X:  objact  ) 
ra::aod-op(  X  )  ft 

VR-Icon-for-Objact?(  ra:  :parant-axpr(  X  )  ) 

— > 

ri::ico&(  a  )  ft  ri: :hoBa-aurfaca(  a  )  »  DS  ft 

ri:  :icon-typa(  a  )  »  'ri::allipsa  ft 
ri:  :haight -width-ratio (  a  )  -  1.0  ft 
ri::labal(  a  )  *  [  "MOD"  ]  ft 

ri:  :clip-icon-labal?(  a  )  »  falsa  ft 

VR-Objact-lor-Icon(  a  )  *  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::lioh(  b  )  ft  ri: :hoBa-surlaca(  b  )  «  DS  ft 

ri: :aourca(  b  )  =  a  ft 

ri:  :targat(  b  )  s 
VR-lcon-lor-Obj act ( 

ra: :parant-axpr(  X  ))  ft 

ri: :d]maBic?(b)  *  true 


rula  VR-Intagar-To-Raal-Op(  X:  objact  ) 
ra:  :intagar-to-raal-op(  X  }  ft 
VR-Icon-lor-Objact?(  ra:  :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBa-surfaca(  a  )  ■  DS  ft 

ri : : icon-t]rpa(  a  }  «  ’ri::allip8a  ft 
ri:  :haight -width-rat io(  a  )  »  1.0  ft 
ri::labal(  a  )  *  [  "->REAL"  ]  ft 
ri: :clip-icon-labal?(  a  )  s  falsa  ft 

VR-Objact-for-Icon(  a  )  «  X  ft 

VR-Icon-for-Objact(  X  )  *  a  ft 

ri::liok(  b  )  ft  ri: :hoBa-surfaca(  b  )  »  DS  ft 

ri: :sourca(  b  )  ^  a  ft 

ri:  :targat(  b  )  « 

VR-Icon-X or-Ob j  act ( 

ra: :parant-axpr(  X  ))  ft 

ri: :djnaBic?(b)  «  trua 
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nil*  VR-Union-Op(  X:  object  ) 
r«: :  union-op  (  X  }  ft 

Vll-Icon-for-Obj«ct?(  r«:  :par«nt-«xpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: :hoBa-aarfaca(  a  )  «  DS  ft 

ri: :icon-typa(  a  )  »  ’ri::allipsa  ft 
ri:  :haight-width-ratio(  a  )  =  1.0  ft 
ri::lab«l(  a  )  «  C  "UIIOI"  ]  ft 
ri:  :c\ip-icon-labal?(  a  )  =  false  ft 

VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-tarfaca(  b  )  »  DS  ft 

ri::aourca(  b  )  =  a  ft 

ri::targat(  b  )  > 

VR- 1 con-f or-Ob j  e  ct ( 

re: :parent-ezpr(  X  ))  ft 

ri:  :dynaaic?(b)  =  true 


rule  VR-Intersection-Op(  X:  object  ) 
re:  :interaection-op(  X  )  ft 
VR-Icon-lor-Object?(  re:  :parent-expr(  X  )  ) 

“> 

ri::icon(  a  )  ft  ri: :hoae-surface(  a  )  »  OS  ft 

ri:: icon-type (  a  )  >  *ri::ellipse  ft 
ri:  :height-vidth-ratio(  a  1.0  ft 
ri::label(  a  )  >  C  "IITERSECT"  ]  ft 
ri: : clip-icon-label? (  a  )  ^  false  ft 

VR-Objeot-for-Icon(  a  )  «  X  ft 

VR-Icon-lor-Object(  X  )  *  a  ft 

ri::link(  b  )  ft  ri:  :hoBe-surface(  b  )  »  DS  ft 

ri::source(  b  )  -  a  ft 

ri::target(  b  )  * 

VR- 1 con-1 or-Ob j  act ( 

re: :parent-expr(  X  ))  ft 

ri:  :dynaBic?(b}  -  true 


rule  VR-Arbitrary-Eleaent-OpC  X:  object  ) 
re:  :arbitrary-eleBent-op(  X  )  ft 
VR-Icon-lor-Object?(  re:  :parent-expr(  X  )  } 

— > 

ri::icon(  a  )  ft  ri: :hoBe-sttrlace(  a  }  *  OS  ft 

ri: :icon-type(  a  )  »  'ri:: ellipse  ft 
ri: :height-widtb-ratio(  a  )  >  i.o  ft 
ri::label(  a  )  =  C  "{?}"  ]  ft 

ri: : clip-icon-label? (  a  )  =  false  ft 
VR-Object-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Object(  X  )  =  a  ft 
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ri::liak(  b  )  t  ri:  :hoB*-aurfac6(  b  )  =  DS 
ri: :sourc«(  b  )  =  a 
ri: :targ«t(  b  )  ~ 

VR-Icon-f or-Obj  act ( 

ra: :paT«nt-«zpr(  X  ))  k 

ri:  :d]rnaBic?(b)  >  trua 


nila  VR-Sat-To-Saq-Op(  X:  objact  ) 
ra: :sat-to-8aq-op(  1  )  k 
VR-Icon-f or-Obj act?(  ra:  :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBa-attrfaca(  a  )  »  DS  ft 

ri: :icon-typa(  a  )  =  'ri::allipsa  ft 
ri: :haigbt-8idth-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  *  [  "->SEQ"  ]  ft 
ri: :clip-icon-labal?(  a  )  -  falsa  ft 

VR-Objact-for-Icon(  a  )  =  X  ft 

VR-Icon-f or-Obj act (  X  )  »  a  ft 

ri::link(  b  )  ft  ri:  :lioBa-sarfaca(  b  )  s  DS  ft 

ri::sourca(  b  )  »  a  ft 

ri: :targat(  b  )  * 

VR-lcon-lor-Ob j  act ( 

ra: :parant-axpr(  X  ))  ft 

ri: :dynaaic?(b)  s  trua 


rula  VR-First-0p(  X:  objact  ) 
ra: :firat-op(  X  )  ft 

VR-Icoii-for-Objact?(  ra:  :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoaa-aurfaca(  a  )  *  DS  ft 

ri:  :icoii-typa(  a  )  «  'ri::allipsa  ft 
ri: :baight-«idtb-ratio(  a  )  s  1.0  ft 
ri::labal(  a  )  *  [  "FIRST"  ]  ft 
ri: : clip-icon- labal?(  a  )  *  falsa  ft 
VR-Objact-for-Icon(  a  )  *  X  ft 

VR-Icon-f  or-Obj  act  (  X  )  =  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-Biirfaca(  b  )  s  DS  ft 

ri:  :sottrca(  b  )  »  a  ft 

ri: :targat(  b  )  > 

VR-Icon-f  or-Obj  act ( 

ra: :parant-azpr(  X  ))  ft 

ri: :dynaaic?(b)  -  trua 


rula  VR-Prapand-ElaBant-To-Saquanca-Op(  X:  objact  ) 
ra:  :prapand-alaaant-to-saqnanca-op(  X  )  ft 
VR-Icon-f  or-Obj  act?(  ra:  :parant-azpr(  X  )  ) 


— > 
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ri::icon(  a  )  ft  ri:  :hoB«-sttrfac«(  a  )  =  DS  ft 

ri:  :icon-t]rpa(  a  )  =  'ri::allipta  ft 
ri: :haight-«idth-ratio(  a  )=  1.0  ft 
ri::labal(  a  )  -  [  "PREPEID"  ]  ft 
ri: :clip-icon-labal?(  a  )  ^  falsa  ft 

VR-Objacv-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-sarfaca(  b  )  ^  DS  ft 

ri: :sourca(  b  )  «  a  ft 

ri::targat(  b  )  » 

VR-Icon-f or-Ob j  act ( 

ra: :parant-axpr(  X  ))  ft 

ri: :dynaBic?(b)  >  trua 

rule  VR-Insart-Elaaant-In-Saquanca-OpC  X:  objact  ) 
ra:  :insart-alaaant-iii-8aquanca-op(  X  )  ft 
VR-Icon-lor-Objact?(  ra:  :parant-azpr(  X  )  ) 

--> 

ri::icon(  a  )  ft  ri:  :hoBa-sarfaca(  a  )  =  DS  ft 

ri: :icon-typa(  a  )  «  'ri::allipsa  ft 
ri:  :haight-vidth-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  «  C  "IISERT"  ]  ft 
ri:  :cllp-icoii-labal?(  a  )  >  falsa  ft 
VR-Objact-for-Icon(  a  )  *  X  ft 

VR-Icon-f  or-Ob  j  act  (  X  )  »  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-siirfaca(  b  )  »  ds  ft 

ri: :soQrca(  b  )  >  a  ft 

ri: :targat(  b  }  » 

VR-Icon-f or-Obj act ( 

ra: :parant-azpr(  X  ))  ft 

ri: :dysaBic?(b)  >  trua 


ml#  VR-Dalata-Elaaaiit-FroB-Saqaanca-OpC  X:  objact  ) 
ra:  :dalata-alaBiant-froB-saqQanca-op(  X  )  ft 
VR-Icon-for-Objact?(  ra: :parant-axpr(  X  )  ) 

— > 

ri::ico&(  a  )  ft  ri:  ;hoBa-sarfaca(  a  )  *  DS  ft 

ri: :icon-typa(  a  )  =  'ri::allip8a  ft 
ri: :haight-*idth-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  ^  C  "DELETE"  ]  ft 
ri: :clip-icon-labal?(  a  )  «  falsa  ft 

VR-Objact-for-Icon(  a  )  =  X  ft 

VR-Icon-f or-0bjact(  X  )  =  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-8iirfaca(  b  )  >  DS  ft 

ri: :sourca(  b  )  =  a  ft 

ri::targat(  b  )  = 

VR-Icon-f or-Obj act ( 

ra: :parant-axpr(  X  ))  ft 

ri:  :dynaBic?(b)  s  tnia 
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rule  VR-L«tt-Op(  X:  obj«ct  ) 
r«::laft-op(  1)  k 

VR-Icon-for-Obj«ct?(  r«:  :par€iit-«zpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoB«-ittrfaca(  a  )  =  DS  ft 

ri:  :icon-typa(  a  )  =  'ri::allipa«  ft 
ri:  :h«ight-«idth-ratio(  a  }  =  1.0  ft 
ri::labal(  a  )  »  [  "LAST"  J  ft 

ri:  :clip-icon-labaI?(  a  )  »  falsa  ft 

VR-Objact-for-Icon(  a  )  =  X  ft 

VR-Icoii-for-Obj#ct(  X  )  *  a  ft 

ri::link(  b  )  ft  ri:  :hoBs-sarfacs(  b  )  >  DS  ft 

ri::80ttrcs(  b  )  »  a  ft 

ri::targst(  b)- 
VR-Icon-for-Objact( 

ra: :parant-azpr(  X  ))  ft 

ri:  :dynaBic?(b)  =  tnia 


rula  VR-Appand-Elaaant-To-Saqiiaiica-Op(  X:  objact  ) 
ra: :appsnd-alaBant-to-saquanca-op(  X  )  ft 
VR-Icon-lor-Objact?(  ra: :parant-azpr(  X  )  ) 

“> 

ri::icon(  a  )  ft  ri:  :hoaa-turlaca(  a  )  «  DS  ft 

ri:  :icon*-typa(  a  )  >  *ri::allipse  ft 
ri:  :haight-«idth-ratio(  a  )  >  1.0  ft 
ri::labal(  a  }  «  C  "APPEID"  ]  ft 
ri:  :clip-icon-labal?(  a  )  >  falsa  ft 

VR-Objaet-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::liiik(  b  )  ft  ri: :hoaa-surfaca(  b  )  «  DS  ft 

ri:  :sourca(  b  )  »  a  ft 

ri:  :targat(  b  )  =. 

VR- 1 con-f or-Ob j  act ( 

ra:  :paraiit-azpr(  X  ))  ft 

ri:  :dynafflic?(b)  *  tma 


rula  VR-Sttbsaquancs-OpC  X:  objact  ) 
ra: :subsaqaanca-op(  X  )  ft 
VR-Icon-for-Objact?(  ra: :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBa-sttrfaca(  a  )  «  DS  ft 

ri:  :icon-typa(  a  )  =  'ri::allipsa  ft 
ri: :haight -width-ratio (  a  )  *  1.0  ft 
ri::labal(  a  )  =  [  "SUBSEQ"  ]  ft 
ri: :clip-icon-labal?(  a  )  *  falsa  ft 
VR-Objact-for-Icon(  a  )  «  X  ft 

VR-Icon-f  or-Ob  j  act  (  X  )  »  a  ft 
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ri::link(  b  )  t  ri:  :hoB«-sttrlac«(  b  )  =  DS 
ri: :aottrc«(  b  )  =  a 
ri: :target(  b  )  = 
VR-Icon-for-Obj*ct( 

ra: :par«nt-expr(  X  ))  k 

ri: :dynaBic?(b)  =  trua 


rula  VR-Saquanca-Concatanata-Op(  X:  objact  ) 
ra: :8aquanca-concatanata-op(  1  )  k 
VR-Icon-for-Objact?(  ra: :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  t  ri:  :hoBa-surfaca(  a  )  ^  DS  k 

ri:  :icoii-typa(  a  )  =  ’ri::allipsa  k 
ri:  :haight-«idtb-ratio(  a  )  =  1.0  R 
ri::labal(  a  )  =  [  "COICAT"  ]  k 
ri:  :clip-icon-labal?(  a  )  =  falsa  k 

VR-Objact-for-Icon(  a  )  *  X  k 

VR-Icon-for-Objact(  X  )  =  a  k 

ri;:link(  b  )  R  ri:  :hoBa-8urfaca(  b  )  >  DS  R 

ri: :sottrca(  b  )  *  a  R 

ri: :targat(  b  )  s 
VR-Icon-lor-Ob j  act ( 

ra: :parant-azpr(  X  ))  R 

ri:  :dynaaic?(b)  =  trua 


rula  VR-Ravarsa-0p(  X:  objact  ) 
ra: :raTar8a-op(  X  )  R 

VR-Icoii-for-Objact?(  ra:  :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  R  ri:  :hoBa-surfaca(  a  )  »  DS  R 

ri : : icon-typa(  a  )  ^  'ri::allip8a  R 
ri:  :haight-«idth-ratio(  a  }  =  1.0  R 
ri::labal(  a  )  -  [  "REVERSE"  ]  R 
ri:  :clip-icoii-labal?(  a  )  s  falsa  R 

VR-Objact-for-Icon(  a  )  =  X  R 

VR-Icon-for-ObjactC  X  )  =  a  R 

ri::liiik(  b  )  R  ri:  :hoBa-surfaca(  b  )  =  DS  R 

ri: :80ttrca(  b  )  s  a  R 

ri: :targat(  b  )  s 
VR-Icon-lor-Objact( 

ra: :parant-azpr(  X  ))  R 

ri: : dynamic? (b)  =  trua 


rula  VR-Saq-To-Sat-0p(  X:  objact  ) 
ra: :saq-to-sat-op(  X  )  R 
VR-Icon-for-Objact?(  ra: :parant-azpr(  X  )  ) 

--> 

ri::icon(  a  )  R  ri:  :hoaa-surlaca(  a  )  =  DS  R 
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ri:  :icoii-typ«(  a  )  =  'ri::allip8«  * 
ri:  :haight-*idth-ratio(  a  }  >  1.0  ft 
ri::labal(  a  )  =  [  •'->SET"  ]  ft 
ri:  :clip-icon-labal?(  a  )  =  falsa  ft 

VR-Objact-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::link(  t  )  ft  ri:  :hoBa-sttrfaca(  b  )  »  DS  ft 

ri:  :aotirca(  b  )  >  a  ft 

ri::targat(  b  )  = 

VR-Icon-for-Objact( 

ra: :parant-azpr(  X  ))  ft 

ri:  :dynaBic''<t»)  »  trua 


rula  VR-Saq-To-Map-0p(  X:  objact  ) 
ra: :aaq-to-Bap-op(  X  )  ft 
VR-Icon-for-Objact?(  ra: :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBa-8urfaca(  a  )  >  DS  ft 

ri: :icon-t7pa(  a  )  «  *ri::allipsa  ft 
ri:  :haight -width-ratio (  a  )  ■  1.0  ft 
ri::labal(  a  )  «  [  "->MAP''  ]  ft 
ri:  :clip-ieon-labal?(  a  )  *  falsa  ft 

VR-Objact-for-Icon(  a  )  »  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::link(  b  )  ft  ri: :hoBa-surfaca(  b  )  «  DS  ft 

ri::sottrca(  b  )  «  a  ft 

ri::targat(  b  )  * 

VR-Icon-f  or-Ob j  act ( 

ra: :parant-azpr(  X  ))  ft 

ri: :dynaBic?(b)  -  trua 


rula  VR-Coaposa-Op(  X:  objact  ) 
ra: :coBpo8a-op(  X  )  ft 

VR-Icon-f or-Ob jact?(  ra: :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoaa-8urfaca(  a  )  s  ps  ft 

ri: :icon-typa(  a  )  ^  'ri::allip8a  ft 
ri:  :haight-width-ratio(  a  )  *  1.0  ft 

ri::labal(  a  )  *  [  "f  o  g"  ]  ft 

ri: :clip-icon-labal?(  a  )  ^  falsa  ft 

VR-Objact-for-Icon(  a  )  =  X  ft 

VR-Icon-f or-Obj  act (  X  )  *  a  ft 

ri::link(  b  )  ft  ri:  :hoaa-surfaca(  b  )  =  DS  ft 

ri::sourca(  b  )  *  a  ft 

ri::targat(  b  )  « 

VR-Icon-f or-Ob j  act ( 

ra: :parent-azpr(  X  ))  ft 

ri: :dynaaic?(b}  =  trua 
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ml*  VR-Inv#rs«-Op(  X:  cbj«ct  ) 
r«:  :inv«rs«-op(  X  )  t 

VR-Icon-for-Obj*ct?(  r«:  :p*r«nt-«xpr(  X  )  ) 

— > 

ri::icon(  a  )  t  ri:  :hoB«-surlac«(  a  )  s  ds  k 

ri:  :icoii-typa(  a  )  >  'ri::allipsa  k 
ri:  :haight-«idth-ratio(  a  )  =  1.0  t 
ri::labal(  a  )  =  [  "1  -1"  ]  k 

ri: :clip-icon-labal?(  a  )  «  falsa  k 
VR-Objact-for-Icoii(  a  )  =  X  k 

VR-Icon-for-Objact(  X  )  =  a  k 

ri::link(  b  )  t  ri:  :hoBa-surfaca(  b  )  «  DS  k 

ri: :sourca(  b  )  =  a  k 

ri: :targat(  b  )  = 
VR-Icon-for-Objact( 

ra:  :paraiit-azpr(  X  ))  k 

ri: :dynaaic?(b)  =  trua 


rula  VR-Map-To-Sat-0p(  X:  objact  ) 
ra:  :Bap-to-sat-op(  X  }  t 
VR-Icon-lor-Objact?(  ra:  :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  t  ri:  :hoBa'Stirfaca(  a  )  ^  ds  t 

ri:  :icon-t7pa(  a  )  >  ’ri::allipsa  ft 
ri:  :haigbt-*idth-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  *  [  ••->REL''  ]  ft 
ri:  :clip-icon*-labal?(  a  )  >  falsa  ft 

VR-Objact-for-lcon(  a  )  =  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::link(  b  )  ft  ri:  :hOBa-8ttrfaca(  b  )  »  DS  ft 

ri::sourca(  b  )  =  a  ft 

ri: :targat(  b  )  » 

VR-Icon-f or-Ob j  act ( 

ra: :parant-azpr(  X  ))  ft 

ri: :d7naBic?(b)  =  tnia 


rula  VR-Closara-Undar-Op(  X:  objact  } 
ra:  :closura-nndar-op(  X  )  ft 
VR-Icon-for-Objact?(  ra:  :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBa-8arfaca(  a  )  =  DS 

ri: :icon-typa(  a  }  =  *ri::allipsa 
ri:  :haight-«idth-ratio(  a  }  =  1.0 
ri::labal(  a  )  =  [  "CLOSURE"  ] 
ri: :cllp-icon-labal?(  a  )  = 
VR-Objact-for-Icon(  a  )  *  X 
VR-Icon-f or-Ob j act (  X  )  *  a 
ri::link(  b  )  ft  ri:  :hoBa-surfaca(  b  }  «  DS 
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k 


ri::8ourc«(  b  )  =  a 
ri::targ«t(  b  )  = 
VR-Icon-for-Objact( 

r«: :parant-«xpr(  X  ))  ft 

ri: :dynaBic?(b)  =  tru* 


rula  VR-Tranaitiv«-Cloiura-Op(  X:  objact  ) 
ra:  :transitiv«-clorai  9-op(  X  )  ft 
V*-Icon-for-Objact?(  ra: :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: :hoaa-aurfaca(  a  )  =  DS  ft 

ri:  :ico/i-typa(  a  )  »  *ri::allip8a  ft 
ri:  :haigbt-vidth-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  =  [  "T-CLOSURE"  ]  ft 
ri: :clip-icon-labal?(  a  )  -  falsa  ft 
VR-Qbjact-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Objact(  X  )  »  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-sttrfaca(  b  )  s  DS  ft 

ri::aourca(  b  )  «  a  ft 

ri::targat(  b  )  > 

VR-Icon-f or-Ob j  act ( 

ra: :parant-azpr(  X  ))  ft 

ri: :dynaBic?(b)  *  trua 


rula  VR-Gat-Fiald'0p(  X:  objact  ) 
ra:  :gat-fiald-op(  X  )  ft 
VR-Icon-lor-Objact?(  ra: :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBa-aurfaca(  a  )  »  ds  ft 

ri:  :icoii-t]rp«(  a  )  »  'ri::allipsa  ft 
ri:  :haight-«idth-ratio(  a  )  ^  1.0  ft 
ri::labal(  a  )  >  [  "GET"  ]  ft 

ri: : clip-icon- labal?(  a  )  -  falsa  ft 

VR-Objact-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::link(  b  )  ft  ri: :hoBa-surfaca(  b  )  =  D5  ft 

ri: :sourca(  b  }  =  a  ft 

ri::targat(  b  }  = 
VR-Icon-for-nbjact( 

ra: :parant-azpr(  X  ))  ft 

ri:  :dynaBic?(b)  trua 


rula  VR-Filtar-Op(  X:  objact  ) 
ra: :filtar-op(  X  )  ft 

VR-Icon-f or-Ob j act? (  ra: :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: :hoBa-surfaca(  a  )  =  DS  ft 

ri:  :icon-typa(  a  )  -  'ri::allipsa  ft 
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ri: :  height -Bidth-ratio(  a  )  -  1.0  k 
ri: : label (  a  )  =  [  "FILTER"  ]  k 
ri: :  clip-icon-label? (  a  )  =  false  k 

VR-Object-for-Icon(  a  )  =  X  k 

VR-Icon-for-Object(  X  )  =  a  k 

ri::link(  b  )  k  ri: thoae-sorfaceC  b  )  =  DS  * 

ri::aottrce(  b  )  =  a  R 

ri: : target (  b  )  « 
VR-Icon-for-Object( 

re: :parent-ezpr(  X  ))  k 

ri: :dynanic?(b)  *  true 


rule  VR-Size-0p(  X:  object  ) 
re: :aize-op(  X  )  ft 

VR-Icon-for-Object?(  re: :parent-ezpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: : hone-surface (  a  )  -  DS  ft 

ri: : icon-type (  a  )  ^  'ri::ellipse  ft 
ri: : height -Bidth-ratio(  a  )  =  1.0  ft 
ri::label{  a  )  =  [  "SIZE"  ]  ft 

ri: : clip-icon-label? (  a  )  «  false  ft 

VR-Object-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Object(  X  )  *  a  ft 

ri::link(  b  )  ft  ri: : hone-surf ace(  b  )  *  DS  ft 

ri::source(  b  )  »  a  ft 

ri::target(  b  )  s 
VR-Icon-f or-Ob j  ect ( 

re: :parent-expr(  X  })  ft 

ri: : dynamic? (b)  *  true 


rule  VR-Donain-0f-Definition-0p(  X:  object  ) 
re:  :doBain-of-definition-op(  X  )  ft 
VR-Icon-for-Object?(  re: :parent-expr(  X.)  ) 

— > 

ri::icon(  a  )  ft  ri: : hone-surf ace(  a  }  ^  ds  ft 

ri: :icon-type(  a  )  =  'ri:: ellipse  ft 
ri: :height-width-ratio(  a  )  »  i.o  ft 
ri::label(  a  )  =  [  "DON"  ]  ft 

ri: : clip-icon- label? (  a  )  =  falsa  ft 

VR-Object-for-Icoa(  a  )  =  X  ft 

VR-Icon-for-Object(  X  )  =  a  ft 

ri::link(  b  }  ft  ri: :hone-surface(  b  )  =  DS  ft 

ri::source(  b  )  =  a  ft 

ri::target(  b  )  = 

VR-Icon-f or-Ob j ect ( 

re: :parent-expr(  X  ))  ft 

ri: : dynamic? (b)  =  true 
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rul«  Vll-IUng«-Op(  X:  object  ) 
re:  :rang«-op(  I  )  t 

VIl-Icon-lor-Object?(  re:  :parent-ezpr(  X  )  ) 

— > 

ri::icon(  a  }  k  ri: :hoBe-8ttrface(  a  )  =  DS  * 

ri: :icon-type(  a  )  =  ’ri::ellipee  ft 
ri: : height -«idth-ratio(  a  }  s  i.o  ft 
ri::label(  a  }  =  [  "RIG”  ]  ft 

ri: :clip-ico&-label?(  a  )  »  false  ft 

VR-Object-lor-Icon(  a  )  »  X  ft 

VR-Icoii-for-Object(  X  )  »  a  ft 

ri::link(  b  )  ft  ri: :hoBe-surfaca(  b  )  =  OS  ft 

ri::sottrce(  b  )  =  a  ft 

ri: :target(  b  )  = 

VR-Icoii-for-Object( 

re: :parant-ezpr(  X  ))  ft 

ri: :dynaaic?(b)  =  true 


rule  VR-Iaage-OpC  X:  object  ) 
re: :iBage-op(  X  )  ft 

VR-Icon-for-Object?(  re:  :pareiit-ezpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: :hoae-surface(  a  )  >  ds  ft 

ri: :icon-t7pe(  a  )  »  ’ri:: ellipse  ft 
ri: :height-«idth-ratio(  a  )  =  1.0  ft 
ri::label(  a  )  =  C  "IMG"  ]  ft 

ri: : clip-icon-label? (  a  )  *  false  ft 

VR-Object-for-Icon(  a  )  »  X  ft 

VR-Icon-lor-Object(  X  )  *  a  ft 

ri::link(  b  )  ft  ri: :hoBe-surface(  b  )  s  DS  ft 

ri::80urce(  b  )  =  a  ft 

ri: :target(  b  )  » 

VR-Icon-lor-Obj  ect( 

re: :parent-ezpr(  X  ))  ft 

ri: :dynaBic?(b)  =  true 


rule  VR-idd-BleBent-To-Set-Op(  X:  object  ) 
re:  :add-eleBent-to-set-op(  X  )  ft 
VR-Icon-lor-Object?(  re:  :parent-ezpr(  X  )  ) 

— > 

ri::icon(  a  }  ft  ri: :hoBe-8urface(  a  )  s  DS 

ri: :icon-type(  a  )  »  'ri::ellip8e 
ri: :height -width-rat io(  a  )  =  1.0 
ri::label(  a  )  *  C  "{+}"  ] 
ri: : clip-icon- label? (  a  }  «  false 
VR-Object-for-Icon(  a  )  =  X 
VR-Icon-for-Object(  X  )  ■  a 
rl::llnk(  b  )  ft  ri: :hoBe-surface(  b  )  s  ds 
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ri: :sottrc«(  b  )  <  a  ft 

ri: :targ«t(  b  )  = 
VR-Icoii-lor-Obj«ct( 

ra: :par«nt-«zpr(  X  ))  ft 

ri:  :dyiiaaic?(b)  =  tni* 


rule  VR-D«l«t«-Elra«nt-FroB-S«t-Op(  X:  objact  ) 
ra:  :dalata-alaBatit-froB-tat-op(  X  )  ft 
VR-Icon-for-Objact?(  ra:  :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: rhoBa-surlacaC  a  )  >  DS  ft 

ri: :icon-typa(  a  )  «  'ri::allip8a  ft 
ri: :haight-8idth-ratio(  a  )  »  i.o  ft 
ri::labal(  a  )  =  [  '•{-}"  ]  ft 

ri: :clip-icon-labal?(  a  )  =  falsa  ft 

VR-Objact-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Objact(  X  )  *  a  ft 

ri::link(  b  )  ft  ri: :hoaa-surfaca(  b  )  >  DS  ft 

ri: :soarca(  b  )  «  a  ft 

ri: :targat(  b  )  « 
VR-Icon-for-Objact( 

ra: :parant-azpr(  X  ))  ft 

ri: :d7naaic?(b)  *  trua 


rula  VR-Trua-0p(  X:  objact  ) 
ra::trua-op(  X  )  ft 

VR-Icon-for-Objact?(  ra: :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: :hoaa-surfaca(  a  )  =  DS  ft 

ri:  :icon-t]rpa(  a  )  >  'ri::allipsa  ft 
ri: :haight-width-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  «  [  "TRUE"  ]  ft 

ri: :clip-icon-labal?(  a  )  =  falsa  ft 
VR-Objact-lor-Icon(  a  )  *  X  ft 

VR-Icon-for-Objact(  X  )  *  a  ft 

ri::link(  b  )  ft  ri: :hoBa-sarlaca(  b  )  s  ds  ft 

ri::sottrca(  b  }  «  a  ft 

ri: :targat(  b  )  s 
VR-I con-1 or-Ob j  act ( 

ra: :parant-axpr(  X  ))  ft 

ri:  :d7naBic?(b)  -  tma 


rula  VR-Falsa-Op(  X:  objact  ) 
ra: :falsa-op(  X  )  ft 

VR-Icon-lor-Objact?(  ra:  :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: :hoBa-surfaca(  a  )  s  ds  ft 

ri: :icon-t7pa(  a  )  *  'ri::allipsa  ft 
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ri: :h«ight-vidth-ratio(  a  )  «  1.0  ft 
ri::labal(  a  )  =  C  "FALSE"  ]  ft 
ri: :clip-icon-labal?(  a  )  =  falsa  ft 

VR-Objact-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::link(  b  )  ft  ri: rhosa-surfacaC  b  )  «  DS  ft 

ri: :sottrca(  b  )  =  a  ft 

ri: :targat(  b  )  « 

VR-Icon-for-Objact( 

ra: :parant-axpr(  X  ))  ft 

ri: :dynaBic?(b)  =  trua 


F.4  Boolean  Icons 


!!  in-packaga("RU") 
!!  in-graauiar('ttsar) 


rula  VR-Top-La»al-Laisar-Op(  X:  objact  ) 
ra:  :?.atsar-op(  X  ) 

— > 

ri::icon(  a  }  ft  ri: :hoaa~sarfaca(  a  )  «  DS  ft 

ri: :icon-typa(  a  )  =  'ri::allipsa  ft 
ri:  :haight-*idth-ratio(  a  )  >  1.0  ft 
ri::labal(  a  )  =  [  "<"  ]  ft 

ri: :clip-icon-labal?(  a  )  -  falsa  ft 
VR-Objact-for-Icon(  a  )  »  X  ft 

VR-Icon-for-ObjactC  X  )  »  a 


rula  VR-Eabaddad-Lassar-OpC  X:  objact  ) 
ra: :lassar-op(  X  )  ft 

VR-Icon-for-Objact?(  ra;  :parant-azpr(  X  )  ) 

— > 

ri::ico&(  a  )  ft  ri:  :hoaa-sarfaca(  a  )  >  DS  ft 

ri:  ;icon-t]rpa(  a  )  «  'ri::allipsa  ft 
ri: :haight -width-rat io(  a  )«  1.0  ft 
ri::labal(  a  )  *  [  "<"  ]  ft 

ri: : clip-icon- labal?(  a  )  -  falsa  ft 

VR-Objact-for-Icon(  a  )  »  X  ft 

VR-Icon-for-Objact(  X  )  *  a  ft 

ri::link(  b  )  ft  ri: :hoBa-sttrfaca(  b  )  «  DS  ft 

ri::aottrca(  b  )  «  a  ft 

ri: :targat(  b  )  = 

VR-Icon-f or-Ob j  act ( 

ra: :parant-axpr(  X  })  ft 
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ri:  :d]rnaBic?(b)  >  tru* 


nil*  VR-Top-L«v«l-L««i«rOrEqttal-Op(  X:  object  ) 
re: :l«ts«ror«qaal-op(  X  ) 

— > 

ri::icon(  a  )  t  ri: :hoae-eurlace(  a  )  =  DS  t 

ri: :icon-typa(  a  )  =  ’riirellipse  t 
ri: :height-vidth-ratio(  a  )  =  1.0  ft 
ri::label(  a  )  =  [  "<="  ]  ft 

ri: : clip-icon-label? (  a  )  s  false  ft 
VR-Object-lor-Icon(  a  )  =  X  ft 

VR-Icon-for-Object(  X  )  *  a 


rule  VR-Embedded-LesaerOrEqual-Op(  X:  object  ) 
re: :leaseroreqttal-op(  X  )  ft 
VR-Icon-for-Object?(  re: :parent-expr(  X  )  ) 

— > 

rl::icon(  a  )  ft  ri: : hone-surf ace(  a  )  «  DS  ft 

ri: :icon-t7pe(  a  }  s  *ri::ellipse  ft 
ri: :height-*idth-ratio(  a  )  >  1.0  ft 
ri::label(  a  )  *  [  "<="  ]  ft 

ri: : clip-icon-label? (  a  )  ‘  false  ft 

VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-lor-Object(  X  )  *  a  ft 

ri::link(  b  )  ft  ri: :hoae-surface(  b  )  -  DS  ft 

ri::source(  b  )  «  a  ft 

ri::target(  b  )  = 

VR-Icon-f or-Ob j  ect ( 

re: :parent-ezpr(  X  ))  ft 

ri: :dynaBic?(b)  ^  true 


rule  VR-Top-Level-Greater-Op(  X:  object  ) 
re: : great er-op(  X  ) 

— > 

ri::icon(  a  )  ft  ri: :hoae-surface(  a  )  =  DS  ft 

ri: :icon-tjpe(  a  )  s  'ri::ellipsa  ft 
ri: :height-»idth-ratio(  a  }  =  1.0  ft 
ri::label(  a  )  =  [  ">”  ]  ft 

ri: : clip-icon-label? (  a  )  =  false  ft 
VR-Object-for-Icon(  a  )  =  X  ft 

VR-Icon-for-Object(  X  )  *  a 


rule  VR-Enbedded-Greater-Op(  X:  object  ) 
re: :greater-op(  X  )  ft 

VR-Icon-f or-Ob j ect? (  re: :parent-ezpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: :hone-8urface(  a  )  =  DS  ft 
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ri: :icon-typ«(  a  )  »  'ri;:«liips«  ft 
ri: ;haight-«idth-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  =  [  •'>"  ]  ft 

ri: :clip-icon-labal?(  a  }  s  lalaa  ft 

VR-Objact-lor-Icon(  a  )  *  X  ft 

VR-Icon-for-Objact(  X  )  *  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-8urlaca(  b  )  s  ds  ft 

ri: :sottrca(  b  )  =  a  ft 

ri: :targat(  b  )  « 

VR-Icon-for-Objact( 

ra: : parent -axprC  X  ))  ft 

ri: :dynaBic?(b)  =  true 


mla  VR-Top-Laval-GraatarOrEqual-Op(  X:  object  ) 
re: :greaterorequal-op(  X  ) 

“> 


ri::icon(  a  )  ft  ri:  :hoBe-eurface(  a  )  s  ds  ft 

ri: : icon-type (  a  )  =  'ri::ellip8a  ft 
ri: :height-eidth-ratio(  a  )  ^  i.o  ft 
ri::label(  a  )  «  [  ''>«'•  ]  ft 

ri: : clip-icon-label? (  a  )  ^  falee  ft 
VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Object(  X  )  *  a 


rule  VR-EBbedded-GreaterOrEqttal-Op(  X:  object  ) 
re:  :greaterorequal-op(  X  )  ft 
VR-Icon-lor-Object?(  re:  :parent-expr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBe-8urlace(  a  )  -  DS  ft 

ri:  :icon-type(  a  )  ■  .'ri:  :ellip8e  ft 
ri: : height -*idth-ratio(  a  )>  1.0  ft 
ri::label(  a  )  =  [  ”>*"  ]  ft 

ri: :cllp-icon-labfl?(  a  )  «  fait*  r 

VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-ior-Object(  X  )  *  a  ft 

ri::link(  b  )  ft  ri:  :hoBe-sttrfaca(  b  )  =  DS  ft 

ri: :«ource(  b  )  <  a  ft 

ri: :target(  b  )  = 

VR-Icon-f or-Ob j  ect ( 

re: :parent-expr(  X  )}  ft 

ri: :dynanic?(b)  s  true 


rule  VR-Top-Level-Iot-Op(  X:  object  ) 
re::not-op(  X  ) 

“> 

ri::icon(  a  )  ft  ri:  :hoBe-8urface(  a  )  ■  DS  ft 

ri: :icon-type(  a  )  »  ’ri::ellip8e  ft 
ri: : height -width-ratio (  a  )  ^  1.0  ft 
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ri:  :lab«l(  a  )  -  [  "lOT"  ]  t 
ri: ;clip-icon-labal?(  a  )  »  falsa  k 
VR-Objact-for-Icc'n(  a  )  »  X  k 
VR-Icon-for-Objact(  X  )  =  a 


ml#  VR-EBbaddad-lot-Op(  X:  objact  ) 
ra::not-op(  1  )  k 

VR-Icon-for-Objact?(  ra: :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  t  ri:  :hoaa-8iirfaca(  a  )  >  DS  k 

ri: :icon-typa(  a  )  =  'ri::allip8a  k 
ri: :haight-«idth-ratio(  a  )  ^  1.0  R 
ri::labal(  a  )  *  [  '‘lOT"  ]  k 

ri: :clip-icon-labal?(  a  )  «  falsa  k 

VR-Objact-for-Icon(  a  )  *  X  k 

VR-Icon-for-Objact(  X  )  *  a  k 

ri::link(  b  )  R  ri:  :hoBa-8tirfaca(  b  )  >  DS  R 

ri:  :8oarca(  b  )  =  a  R 

ri:  :targat(  b  )  > 

VR-Icon-f or-Ob j  act ( 

ra: :parant>axpr(  X  ))  R 

ri:  :dyaaBic?(b)  «  trua 


mla  VR-Top-Laval-I«plia8-0p(  X:  objact  ) 
ra: :iaplia8-op(  X  ) 

— > 

ri::icon(  a  )  R  ri:  :hoaa-8urfaca(  a  )  *  DS  R 

ri: :icon-t7pa(  a  )  «  'ri::allip8a  R 
ri: :haigbt>«idth-ratio(  a  )  s  i.o  R 
ri::labal(  a  )  *  C  "**«>"  ]  R 

ri:  :clip-icoii-labal?(  a  )  »  falsa  R 
VR-Objact-for-Icon(  a  )  »  X  R 

VR- Icon-f or-Ob j act (  X  )  =  a 


rula  VR-'Eabaddad-Iaplias-OpC  X:  objact  ) 
ra: ;iBplias-op(  X  )  R 

VR-Icon-f  or-Ob  j  act  ?(  ra:  :paraiit-axpr(  X  )  ) 

“> 

ri::icon(  a  )  R  ri:  :hoaa-surfaca(  a  )  *  DS 

ri:  :icoii-typa(  a  )  >  'ri::allip8a 
ri: :haight-width-ratio(  a  )  =  1.0 
ri::labal(  a  )  =  [  "=*=>••  ] 
ri: :clip-icon-labal?(  a  )  s  falsa 
VR-Objact-for-Icon(  a  )  =  X 
VR-Icoa-for-Objact(  X  )  *  a 
ri::link(  b  )  R  ri:  :hoaa-surfaca(  b  )  s  DS 
ri::sourca(  b  }  e  c 
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ri::targ«t(  b  )  * 

VR-Icon-f or-Ob j  ^ct ( 

r«: :par«nt-«xpr(  X  ))  k 

ri: :  dynamic?  (b)  >  trua 


rula  VR-Top-Laval-And-Op(  X:  object  ) 
r«::and-op(  X  )  R 

'VR-Icon-for-Obj€ct?(  ra: :parant-axpr(  X  )  ) 

“> 

ri::icon(  a  )  R  ri:  :hoaa-surfaca(  a  )  =  DS  R 

ri: :icon-typa(  a  )  s  *ri::allipsa  R 
ri:  :haight-nidth-ratio(  a  )  s  1.0  R 
ri::labal(  a  )  =  [  “AID"  ]  R 

ri: :clip-icon-labal?(  a  )  =  falsa  R 
VR-Objact-for-Icon(  a  )  =  X  R 

VR-Icon-for-Objact(  X  )  =  a 


rula  VR-Eabaddad-And-Op(  X:  object  ) 
ra::and-op(  X  )  R 

VR-Icon-for-Objact?(  ra: :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  R  ri: :hoBa'snrfLca(  a  )  *  DS  R 

ri: :icon-typa(  a  )  *  'ri:: ellipse  R 
ri:  :haight-vidth-ratio(  a  )  «  1.0  R 
ri::labal(  a  )  *  C  "AID"  ]  R 

ri: :clip-icon-labtl?(  a  )  «  falsa  R 

VR-Objact-for-Icca(  a  )  *  X  R 

VR-Icon-for-Objaet(  X  )  =  a  R 

ri::link(  b  )  R  ri:  :hoBa-surfaca(  b  )  =  DS  R 

ri::sourca(  b  }  >  a  R 

ri::targat(  b  }  « 

VR-Icon-f or-Ob j  act ( 

ra: :parant-axpr(  X  ))  R 

ri: : dynamic? (b)  -  trua 


rule  VR-Top-Laval-Ordarad-And-Op(  X:  object  } 
ra: :ordarad-and-op(  X  ) 

— > 

ri::icon(  a  )  R  ri: :lioma-surfaca(  a  }  «  DS  R 

ri: :icon-typa(  a  )  »  'ri:: ellipse  R 
ri:  :haight-«idth-ratio(  a  )  =  1.0  R 
ri::labal(  a  }  =  [  "AID->"  ]  R 

ri: :clip-icon-labal?(  a  )  =  falsa  R 
VR-Objact-for-Icon(  a  )  =  X  R 

VR-Icon-f or-0bjact(  X  )  *  a 


rula  VR-Enbaddad-0rdarad-And-0p(  X:  object  } 
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r«: :ord«r«d-uid-op(  X  )  ft 
VR-Icon-for-Obj«ct?(  r«: :par«nt-6xpr(  X  )  ) 

— > 

ri::icon(  a  }  ft  ri:  :hoB«-surfac«(  a  )  «  OS  ft 

ri:  :icoii-typ«(  a  )  «  'ri::allipBa  ft 
ri: :haight-«idth-ratio(  a  )  =  1.0  ft 
ri::labal(  a  )  >  [  '’AID->"  ]  ft 

ri:  :clip-icon-labal?(  a  )  >  falsa  ft 

VR-Objact-lor-Icon(  a  )  =  X  ft 

VR-Icon-lor-Objact(  X  )  =  a  ft 

ri::link(  b  )  ft  rl:  :hoaa-sttrXaca(  b  )  s  DS  ft 

ri: :aottrca(  b  )  ^  a  ft 

ri: :targat(  b  )  » 

VR-Icon-for-Objact( 

ra: :parant-axpr(  X  ))  ft 

ri: :d7naBic?(b)  =  trua 


rula  VR“Top-Laval-0r-0p(  X:  objact  ) 
ra::or-op(  X  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBa-aiirfaca(  a  )  >  OS  ft 

ri : : icon-typa(  a  )  «  *ri::allipsa  ft 
ri: ;haight-width-ratio(  a  )  -  1.0  ft 
ri::labal(  a  }  «  C  "OR"  ]  ft 

ri:  :clip'icon*'labal?(  a  )  »  falsa  ft 
VR-Objact-for-Icon(  a  )  *  X  ft 

VR-lcoii“for-Objact(  X  )  *  a 


rula  VR-Efflbaddad-Qr-Op(  X:  objact  ) 
ra::or-op(  X  )  ft 

VR-Icon-for-Objact?(  ra: :parant-axpr(  X  )  ) 

— > 

ri::icoxi(  a  }  ft  ri:  :hoBa-surfaca(  a  )  «  OS  ft 

ri : : icon-typaC  a  )  =  'ri;:allipsa  ft 
ri: :haight-*idth-ratio(  a  )  -  1.0  ft 
ii::labal(  a  )  >  [  "OR"  ]  ft 

ri: :clip-icon-labal?(  a  )  s  fais*  t 
VR-Objact-lor-Icon(  a  )  »  X  ft 

VR-Icoa-for-Objact(  X  )  »  a  ft 

ri::lisk(  b  )  ft  ri:  :hoBa-surfaca(  b  }  *  OS  ft 

ri: :sottrca(  b  )  =  a  ft 

ri: :targat(  b  }  > 

VR-Icon-lor-Ob j  act ( 

ra: :parant-axpr(  X  ))  ft 

ri: :d7naaic?(b)  =  trua 


rula  VR-Top-Laval-0rdarad-0r-0p(  X:  objact  ) 
ra: :ordarad-or-op(  X  ) 
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— > 


ri;:icon(  a  }  A  ri:  :hoBa-aurlaca(  a  )  =  DS  A 

ri:  :icon-t]rpa(  a  )  =  ’rirtallipse  A 
ri:  :haight-«idth-ratio(  a  )  »  1.0  A 
ri::labal(  a  )  =  [  "0R->"  ]  A 

ri: :clip-icon-labal?(  a  )  ^  falsa  A 
VR-Objact-lor-Icon(  a  )  =  X  A 

VR-Icon-for-Objact(  X  )  *  a 


rula  VR-EBbaddad-0rdarad-0r-0p(  X:  objact  ) 
ra: :ordarad-or-op(  X  )  A 
VR-Icon-for-Objact?(  ra: :parant-azpr(  X  )  ) 

— > 

ri::icon(  a  )  A  ri:  :hoBa-sttrfaca(  a  )  =  DS  A 

ri:  :icon-typa(  a  )  =  'ri::allip8a  A 
ri:  :haight-vidth-ratio(  a  )  =  1.0  A 
ri::labal(  a  )  =  [  "0R->"  ]  A 

ri: :clip-icon-labal?(  a  )  =  falsa  A 

VR-Objact-for-Icon(  a  )  =  X  A 

VR-Icon-lor-Objact(  X  )  *  a  A 

ri::link(  b  )  A  ri:  :hoaa-surfaca(  b  )  s  DS  A 

ri: :sourca(  b  )  >  a  A 

ri::targat(  b  )  s 
VR-Icon-f or-Ob; act ( 

ra: :parant-azpr(  X  ))  A 

ri:  :dyna»ic?(b)  -  trua 


rula  VR-Top-Laval-ForAll-Op(  X:  objact  ) 
ra: :forall-op(  X  ) 

“> 

ri::icon(  a  )  A  ri:  :hoaa-surlaca(  a  )  »  DS  A 

ri:  :icoii-t]rpa(  a  )  >  'ri::allip8a  A 
ri:  :haight-widtb-ratio(  a  )  *  1.0  A 
ri::labal(  a  }  -  [  "FOR  ALL"  ]  A 
ri: :clip-icon-labal?(  a  )  «  falsa  A 
VR-Objact-lor-Icon(  a  )  =  X  A 

VR-Icon-f or-Ob j act  (  X  )  =  a 


rula  VR-Eabaddad-For All-Op (  X:  objact  ) 
ra: :lorall-op(  X  )  A 

VR-Icon-f  or-Ob  j  act?  (  ra:  :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  )  A  ri:  :hoaa-surfaca(  a  )  «  DS  A 

ri:  :icon-typa(  a  )  >  *ri::allip8a  A 
ri:  :haight-aidth-ratio(  a  )  =  1.0  A 
ri::labal(  a  )  =  [  "FOR  ALL"  ]  A 
ri: :clip-icon-labal?(  a  )  =  falsa  A 
VR-Objact-for-Icon(  a  )  *  X  A 
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VR-Icon-ior-Obj«ct(  1  )  =  a  t 

ri::link(  b  )  t  ri:  :hoB«-surfaca(  b  )  *  DS  ft 

ri::80urca(  b  )  =  a  ft 

ri::targat(  b  )  > 
VR-Icoii-for-Objact( 

ra: :parant-axpr(  X  ))  ft 

ri: :dysaBic?(b)  *  true 


rule  VR-Top-Level-ThereExiat8-0p(  X:  object  ) 
re: :thereexiata-op(  X  ) 

— > 

ri::icon(  a  )  ft  ri:  :hoBe-aurlaca(  a  )  >  DS  ft 

ri:  :icon-type(  a  )  >  'ri::allipie  ft 
ri:  :height-*idth-ratio(  a  )  ^  i.o  ft 
ri::label(  a  )  =  [  "EXISTS"  ]  ft 
ri: :clip-icon-label?(  a  )  s  false  ft 
VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Object(  X  )  =  a 


rule  VR-Eabedded-ThereExists-OpC  X:  object  ) 
re: :thereexists-op(  X  )  ft 
VR-Icon-lor-Object?(  re:  :parent-expr(  X  )  ) 

— >> 

ri::icon(  a  )  ft  ri:  :hoBe-surface(  a  )  >  DS  ft 

ri:  :icoii-type(  a  )  =  'ri:  .’ellipse  ft 
ri: : height -*idth-ratio(  a  )  *  1.0  ft 
ri::label(  a  )  -  [  "EXISTS"  ]  ft 
ri: : clip-icon-label? (  a  )  *  false  ft 
VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Object(  X  )  *  a  ft 

ri::link(  b  )  ft  ri: : hone-surf ace(  b  )  ^  DS  ft 

ri::source(  b  )  >  a  ft 

ri: :target(  b  )  *, 

VR- 1 con-f or-Ob j  act ( 

re: :parent-expr(  X  ))  ft 

ri: :dynanic?(b)  -  true 


rule  VR-Top-LeTel-Subset-Op(  X:  object  ) 
re: :subset-op(  X  ) 

— > 

ri::icon(  a  )  ft  ri: : hone-surf ace(  a  )  ^  OS  ft 

ri:  :icon-type(  a  )  =  'ri::ellip8e  ft 
ri:  :height-width-ratio(  a  )  =  1.0  ft 
ri::label(  a  )  <  [  "SUBSET"  ]  ft 
ri: : clip-icon- label? (  a  )  =  false  ft 
VR-Object-for-Icon(  a  )  »  X  ft 

VR-Icon-for-Object(  X  )  =  a 
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rul*  VR-EBb«dd«d-Subs«t-Op(  X:  obj«ct  ) 
r«: :tubt«t-op(  I  )  t 

VR-Icon-for-Obj«ct?(  r«: :par«nt-«xpr(  X  )  ) 

— > 

ri::icon(  a  )  ft  ri: :hoBa-attrfac«(  a  )  =  DS  ft 

ri;  .‘icon-typaC  a  )  ^  *ri::allips8  ft 
ri: :haight-«idth-ratio(  a  )  -  1.0  ft 
ri::labal(  a  )  «  [  "SUBSET"  ]  ft 
ri: :clip-icon-labal?(  a  )  =  falsa  ft 

VR-Objact-for-Icon(  a  )  »  X  ft 

VR-Icon-for-Objact(  X  )  =  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-sttTfaca(  b  )  s  ds  ft 

ri::sottrca(  b  )  «  «  t 

ri: :targat(  b  )  « 

VR-Icon-f or-Ob j  act ( 

ra: :paraat-axpr(  X  ))  ft 

ri: :dynaaic?(b)  =  trua 


rula  VR-Top-Laval-Equal-Op(  X:  objact  ) 
ra:  :aqual-op(  X  ) 

— > 

ri::ieon(  a  )  ft  ri:  :hoBa-surlaca(  a  )  ■  DS  ft 

ri: :icon-t7pa(  a  )  «  ’ri::allipsa  ft 
ri:  :haigbt-Bidth-ratio(  a  )  »  1.0  ft 
ri::labal(  a  )  =  [  "»"  ]  ft 

ri: :clip-icon-labal?(  a  )  =  falsa  ft 
VR-Objaet-for“Icon(  a  )  =  X  ft 

VR-Icon*for-Objact(  X  )  »  a 


rula  VR-EBbaddad-Equal-Op(  X:  objact  } 
ra : :  aqual-op(  X  )  ft 

VR-Icon-f or-Ob j act? (  ra: :parant-axpr(  X  )  ) 

— > 

ri::icon(  a  }  ft  ri:  :hoBa-surfaca(  a  )  «  DS  ft 

ri:  :icon-typa(  a  }  *  *ri;:allipsa  ft 
ri: :haight-vidth-ratio(  a  }  =  1.0  ft 
ri::labal(  a  )  =  [  "="  ]  ft 

ri: :clip-icon-labal?(  a  )  «  falsa  ft 
VR-Objact-for-Icon(  a  )  »  X  ft 

VR-Icon-f or-Obj act (  X  )  «  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-sarfaca(  b  )  »  DS  ft 

ri: :80urca(  b  )  =  a  ft 

ri: :targat(  b  )  = 

VR-Icon-f or-Obj act ( 

ra: :parant-axpr(  X  ))  ft 

ri: :dynaBic?(b)  =  trua  . 
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rul*  VR-Top-L«T«1-Nrab«r-Op(  X:  object  ) 
re:  :B«ib«r-op(  X  ) 

— > 

ri::icon(  a  )  k  ri:  :hoB«-surlac«(  a  )  ^  DS  k 

ri: :icon-t7pa(  a  )  =  'ri::allip8«  * 
ri: :haight-«idth-ratio(  a  )  =  1.0  * 
ri: : label (  a  )  >  [  "MEMBER"  ]  k 
ri: : clip-icon-label? (  a  )  =  false  k 
VR-Object-for-Icon(  a  )  =  X  k 

VR-Icon-for-Object(  X  )  =  a 


rule  VR-Embedded-Menbor-Op(  X:  object  ) 
re: :BeBber-op(  X  )  t 

VR-Icon-for-Object?(  re: :parent-expr(  X  )  ) 

— > 

ri::icon(  a  )  A  ri:  :hoBe-8ttrface(  a  )  =  DS  k 

ri: :icon-type(  a  )  ^  *ri:: ellipse  k 
ri: : height -width-rat io(  a  )  =  1.0  A 
ri: : label (  a  )  >  [  "MEMBER"  ]  A 
ri: :clip-icon-label?(  a  )  =  false  A 
VR-Object-for-Icon(  a  )  *  X  A 

VR-Icon-lor-Object(  X  )  *  a  A 

rl::link(  b  )  A  ri:  :hoBie-aurface(  b  )  «  OS  A 

ri::soarce(  b  )  *  a  A 

ri::target(  b  ) 

VR-Icon-for-Object( 

re: :parent-expr(  X  ))  A 

ri: :dynaaic?(b)  *  true 


rule  VR-Top-LeYel-E«pty-Op(  X:  object  ) 
re: :ewpty-op(  X  } 

- > 

ri::icon(  a  }  A  ri:  :hoBe-surface(  a  )  «  DS  A 

ri: :icon-type(  a  )  =  'ri:: ellipse  A 
ri:  :height-width-ratio(  a  )  -  1.0  A 
ri::label(  a  )  *  C  "0  ?"  ]  A 

ri: : clip-icon-label? (  a  )  =  false  A 
VR-Object-for-Icon(  a  )  *  X  A 

VR-Icon-for-Object(  X  )  »  a 


rule  VR-Eabedded-Eapty-OpC  X:  object  } 
re: :eapty-op(  X  )  A 

VR-Icon-for-Object?(  re: :parent-expr(  X  )  ) 

— > 

ri::icon(  a  )  A  ri:  :hoBe-8urface(  a  )  ^  DS  A 

ri:  :icon-type(  a  )  *  ’ri::ellipse  A 
ri:  :helght-width-ratio(  a  )  =  1.0  A 
ri::label(  a  )  *  [  "0  ?"  ]  A 
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ri: :clip-lcon-lab«l?(  a  )  =  falsa  t 

VR-Objact-for-Icon(  a  )  »  X  t 

VR-Icon-for-Objact(  X  )  =  a  k 

ri::liiik(  b  )  t  ri:  :hoBa-surlaca(  b  )  =  DS  k 

ri: :sottrca(  b  )  =  a  k 

ri::targat(  b  )  = 

VR-Icon-f or-Ob j  act ( 

ra: :parant-axpr(  X  ))  k 

ri: :dynaBic?(b)  >  tnia 


F.5  Binding  [cons 


!!  in-packaga("RU") 
!!  in-graaaarC’aaar) 


rula  VR-Binding(  X:  objact  ) 
ra: :binding(  X  )  ft 
'VR-Icon-for-Objact?(  X  )  ft 
■ In-Binding-List? ( 

C  syBbol-to-string(  ra::naBa(  X  ))  ] 
) 

— > 


ri::icon(  a  )  ft  ri: :homa-sarfaca(  a  )  «  DS  ft 

ri: :icon-tjpa(  a  )  »  ’ri::box  ft 
ri: :haight-width-ratio(  a  )»  0.5  ft 
ri::labal(  a  )  « 

C  synbol-to-string( 

ra::naaa(  X  )  )  ]  ft 

ri:  :clip-icon-labal?(  a  )  >:  falsa  ft 
VR-Objact-for-Icon(  a  )  =  X  ft 

binding-list  »  binding-list  with  a  ft 

ri::link(  b  )  ft  ri:  :hoBa-surfaca(  b  )  =  DS  ft 

ri: :sottrca(  b  )  » 

VR-Icon-f  or-Ob j  act ( 

ra: :parant-axpr(  X  ))  ft 

ri::targat(  b  )  >  a  ft 

ri: :dynaBic?(b)  =  trua 


rula  VR-0bjact(  X:  objact  ) 
ra:  :oparation(  X  )  ft 

ra: :bindingnaBa(  ra: :data-typa(  ra::raf-to( 

ra::rator(  X  ))))  *  * OB JECT-CLiSS 

— > 
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ri::icon(  a  )  ft  ri: :hoBa-turfaca(  a  )  =  DS  ft 

ri: :icon-typa(  a  )  =  ’ri::box  ft 
ri: :haight-width-ratio(  a  )  >  0.5  ft 
ri; :highlight-atyla(  a  )  = 

*rl: :r«varsa-vidao  ft 

ri::labal(  a  )  > 

C  lyBbol-to-atringC 
ra: :bindingnama( 

r«::rator(  X  )))  ]  ft 
ri: :clip-icon-labal?(  a  )  »  falsa  ft 
VR-Objact-lor-Icon(  a  )  *  X  ft 

binding-list  -  binding-list  with  a  ft 

ri::link(  b  )  ft  ri: :hoaia-sttrfaca(  b  )  -  DS  ft 

ri::80ttrca(  b  )  =  a  ft 

ri: :targat(  b  )  - 

VR-Icon-for-Obj  act{ 

ra: :parant-axpr(  X  ))  ft 

ri:  :dynaiiic?(b)  »  trua 


rula  VR-Data-Uith-Qbjact-Link(  X:  objact  ) 
ra: :oparation(  X  )  ft 
In-Binding-List? ( 

C  syabol-to-stringC  ra: :bindingnaBa( 
firstC  ra::aps(  X  ))))  ] 

)  ft 

ra:  :powamapping-op( 

ra: :data-typa(  ra::raf-to(  ra::rator(  X  )  )  ) 

) 

“>  . 

ri::icon(  a  )  ft  ri: :hoBa-surfaca(  a  )  s  DS  ft 

ri: :icon-typa(  a  )  =  'ri;:box  ft 


ri: :haight-*idtb-ratio(  a  )  *  0.6  ft 
ri::labal(  i  )  - 
C  syBibol-to-string( 
ra: :bindingnBBa( 

ra::rator(  X  )))  ]  ft 

ri; :clip-icon-labal?(  a  )  *  falsa  ft 
VR-Objact-for-Icon(  a  )  =  X  ft 

binding-list  -  binding-list  vitb  a  ft 

rl::link(  b  )  ft  ri: :hoBa-surfaca(  b  )  *  DS  ft 

ri: :sourca(  b  )  » 

VR-Icon-f or-Ob j  act ( 

ra: :parant-axpr(  X  ))  ft 

ri::targat(  b  )  »  a  ft 

ri; ;dynaBic?(b)  =  trua  ft 

ri::link(  c  )  ft  ri: :hoBia-8urfaca(  c  )  =  DS  ft 

ri::sourca(  c  )  «  a  ft 


ri;:targat(  c  )  *  Gat-BL-Icon( 
C  8yaibol-to-8tring( 
ra: :bindingnaBa( 
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firBt(  r«: :aps(  X  ))))  ] 

)  * 

ri:  :dynaBic?(  c  )  »  tru* 


rule  VR-Data-tfithoat-Objact-Link(  X:  objact  ) 
ra: ;op8ration(  X  )  t 

ra: :powarBapping-op(  ra:  idata-typaC  ra: :ral-to( 

ra: :rator(  X  }))) 

— > 

ri::icon(  a  )  t  ri: :hoBa-turfaca(  a  )  «  DS  k 

ri: :icon-typa(  a  )  «  ’ri::box  k 
ri: :haight-width-ratio(  a  )  s  o.S  k 
ri::labal(  a  )  « 

[  ayBbol-to-stringC 
ra: :bindingnaBa( 

ra: :rator(  X  )))  ]  k 

ri: :clip-icon-labal?(  a  )  »  falsa  k 
VIl-Objact-for-Icon(  a  )  *  X  k 

binding-list  «  binding-list  with  a  k 

ri::link(  h  )  k  ri: :hoBa-sttrfaca(  b  )  «  DS  k 

ri::aourca(  b  )  =  a  k 

ri::targat(  b  )  ^ 

VR-Ieon-lor-Ob j  act ( 

ra: :parant-axpr(  X  ))  k 

ri: :dynaBic?(b)  •  trua 


rula  VR-Binding-Raf-Baild-Icon(  X:  objact  ) 
ra: :binding-raf (  X  )  * 

'ra:  :satforBar-op(  ra:  :parant-axpr(  X  )  )  k 
* In-Binding-List? ( 

C  syabol-to-stringC  ra:  :bindingnaBa(  X  )  }  ]  ) 

— > 

ri::icon(  a  )  k  ri: :hona-Burfaca(  .a  )  »  DS  k 

ri: :icon-typa(  a  )  s  'ri::box  k 
ri: :haight-width-ratio(  a  )  =  0.5  k 
ri::labal(  a  )  ^ 

C  syabol-to-stringC 

ra:  :bindingnaBia(  X  ))  ]  k 
ri: :clip-icon-labal?(  a  )  s  falsa  k 


VR-Objact-lor-Icon(  a  )  «  X  k 

binding-list  «  binding-list  with  a  k 

ri::link(  b  )  k  ri: :hoBa-sttrfaca(  b  )  >  DS  k 

ri::sottrca(  b  )  =  a  k 

ri::targot(  b  )  = 

VR-I con-f or-Ob j  act ( 

ra: :parant-axpr(  X  ))  k 

ri:  :dynaBic?(b)  *  tma 
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rul«  VR-Binding-ll«l-Link-Icon(  X:  object  ) 
r«: : binding-ref (  I  )  ft 

*re:  :setfoxBer-op(  re:  :parent-expr(  X  )  )  ft 
In-Binding-List?  (  C  iynbol-to-string{ 

re: :bindingnaae(  X  )  )  ]  ) 

— > 

ri::link(  b  )  ft  ri: : hone-surf see (  b  )  ^  ds  ft 

ri: :source(  b  )  s 
Get-BL-Icon( 

C  synbol-to-stringC 

re: :bindingnene(  X  ))  ] 

)  ft 

ri::terget(  b  )  = 

VR-Icon-f or-Obj  ect( 

re: :perent-ezpr(  X  ))  ft 
ri: :dynaBic?(b)  s  true 


F.6  Miscellaneous  Icons 


!!  in-p»ckage("RU'') 
!!  in-graaBsr(*user) 


^  sssxxsxssatsaBsssscsssssxssccsassssscssssxssscssssBsssssxss 

y.  The  folloeing  rules  are  all  represented  by  the 
%  Refine  'operation'  operator.  Therefore,  the  precondition 
X  needs  further  restrictions,  in  order  to  determine  when 
X  each  rule  should  be  applied. 

ssssssssrxsssxszsszsssszszxszsssssxsssxsssssssssssssssss 


rule  VR-lth-Elenent-Op(  X:  object  ) 
re: :operation(  X  }  ft 
In-Blnding-List? ( 

[  synbol-to-stringC  re:  :bindingnane(  re::rator(  X  )))  ] 

)  ft 

Vl-Icon-for-Object?(  re:  :parent-ezpr(  X  )  ) 

“> 

ri::icon(  a  )  ft  ri: :hone-surfaca(  a  )  «  DS  ft 

ri: :icon-type(  a  )  «  'ri::ellipse  ft 
ri: :hoight-widtb-ratio(  a  )  -  1.0  ft 
ri::label(  a  )  [  "1th"  ]  ft 

ri :: clip-icon-label? (  a  )  s  false  ft 

VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Object(  X  )  =  a  ft 

ri::link(  b  )  ft  ri: : hone-surface (  b  )  «  OS  ft 

ri: :source(  b  }  =  a  ft 
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ri: :targ«t(  b  )  = 

VR-Icon-1 or-Ob j  tct ( 

ra: :par«nt-«xpr(  X  ))  * 

ri: :dynaaic?(b)  s  trua 


rula  VR-Top-Laval-Function-Call(  X:  objact  ) 
ra: :oparation(  X  } 

— > 

ri::icon(  a  )  R  ri: :hoBa-aurfaca(  a  )  *  DS  k 

ri:  :icon-typa(  a  )  -  'ri:  .‘dianond  t 
ri: :haight-width-ratio(  a  )  ^  O.S  k 
ri::labal(  a  )  s  [ 

syabol-to-stringC  ra: :bindingnaBa( 
ra: :rator(  X  )))  ]  k 

ri: :clip-icon-labal?(  a  )  =  falsa  k 
VR-Objact-for-Icon(  a  )  =  X 


rula  VR-Eabadad-Function-CalK  X:  objact  ) 
ra: :oparation(  X  ) 

— > 

ri::icon(  a  )  R  ri: :hoBa-tarfaca(  a  )  «  DS  R 

ri: :icon-typa(  a  )  «  ’ri::diaBond  R 
ri:  :haight-width''ratio(  a  )  «  0.6  R 
ri::labal(  a  )  =  C 

syBbol-to-string(  ra: :biodingnaBa( 


ra::rator(  X  )}^  ]  R 

ri: :clip-icon-labal?(  a  )  ^  falsa  R 
VR-Objact-for-Icon(  a  )  =  X  R 

ri::link(  b  )  R  ri: :hoBa-sarfaca(  b  )  ^  ds  R 

ri: :sourca(  b  )  s  a  R 

ri::targat(  b  )  = 

VR-Icon-f or-Ob j act ( 

ra: :parant-axpr(  X  ))  R 

ri:  :dynaBiic?(b)  =  trua 


rula  VR-Erasa-Objact-OpC  X:  objact  ) 
ra: :oparation(  X  )  R 

ra:  :biiidingnaBa(  ra::rator(  X  )  )  =  'arasa-objact 
“> 

ri::icon(  a  )  R  ri: :hoBa-surfaca(  a  )  =  DS  R 

ri: :icon-typa(  a  )  «  'ri::allipsa  R 
ri: :haight-«idth-ratio(  a  )  =  1.0  R 
ri::labal(  a  )  «  [  "ERASE"  ]  R 
ri: :clip-icon-labal?(  a  )  -  falsa  R 
VR-Objact-for-Icon(  a  )  ■  X  R 

VR-Icon-f or-Ob j act (  X  )  ■  a 
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ml#  VR-M«k«-Obj«ct-Op(  X:  object  ) 
r«: : operation (  I  )  ft 

rt:  :bindingnaB«(  r«::rator(  X  )  )  <  'aaka-objact 
— > 

ri::icon(  a  )  ft  ri: :hoBa-«ttrfaca(  a  )  =  DS  ft 

ri : : icon-typ«(  a  )  s  'ri::allipta  ft 
ri: : height -width-ratio (  a  )  ^  i,o  t 
ri::lab«l(  a  )  «  C  "MAKE"  ]  ft 
ri : : clip-icon-labal? (  a  )  =  falsa  ft 


VR-Objact-for-Icon(  a  )  =  X  ft 

VR-lcon-for-Objact(  X  )  =  a  ft 

ri: : highlight-style (  VR-Icon-<or-Object( 

re: : parent -ezpr(  X  ))  )  = 

’ri: :reverse-video  ft 
ri::link(  b  )  ft  ri: : hone-surf ace(  b  )  =  DS  ft 

ri: :sottrce(  b  )  »  a  ft 

ri::target(  b  )  > 

VR-Icon-for-Object( 

re: :parant-expr(  X  ))  ft 

ri: :d7nanic?(b)  =  true 


rule  VR-Diaplay-Qbject-Op(  X:  object  ) 

re: :bindingnaBef  re::rator(  X  )  )  >  ’format  ft 
re: : operation (  X  ) 

— > 

ri::icon(  a  )  ft  ri:  :hone-surface(  a  )  >  DS  ft 

ri: :icon-type(  a  )  «  ’ri::ellipse  ft 
ri: :height-eidth-ratio(  a  )  s  i.o  ft 
ri::label(  a  )  =  [  "DISPLAY"  ]  ft 
ri: : clip-icon-label? (  a  )  »  false  ft 
VR-Object-for-Icon(  a  )  *  X  ft 

VR-Icon-for-Object(  X  )  =  a 
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Appendix  G.  Place’s  Refine^ Specification  for  Kemmerer's 

Library  Problem 


This  appendix  contains  a  Refine  specification  for  Kemmerer’s  library  problem 
discussed  in  Chapter  IV.  This  specification  is  a  slightly  modified  version  of  Place's 
Peine  specification  found  in  (15:Appendix  F). 


!!  in-packag«("RU") 

!!  in-graoBurC ’us«r) 

var  LIBRARY-VORLD-OBJECT:  objtct-claas  aubtyp«-ol  uaar-objact 


var  BOOK:  objact-clasa  aubtypa-of  library-aorld-objact 
var  USER:  obj«ct*claaa  aubtypa-ol  library-aorld-objact 

font  DECURE-LIBRARY-UIIQUE-IANES-CUSSES 
uniqua-nauBta-claas  (  'book,  trua  )  k 
oniqua-naata-claas  (  'uaar,  tnia  ) 


X - Dafina  tha  attrlbvtaa  ol  a  book 


var  BOOX'OUT:  aapC  book,  boolean  )  {11} 
var  01-SHELF:  aiap(  book,  boolaan  )  *  {||} 
var  TITLE-OF-BOOK:  aapC  book,  atring  )  =  {||} 
var  AUTHOR-OF-BOOK :  aiap(  book,  atring  )  «  {11} 
var  SUB JECT-OF-BOOK :  aapt  book,  aat(  atring  )  )  -  {||} 
var  LAST-CHECKED-OUT-BY:  aapC  book,  atring  }  »  {11} 


X - Dafina  tha  attributaa  of  a  uaar  ■ 

var  CUSTOMER:  aapC  uaar,  boolaan  )  >  {11} 
var  STAFF:  aapC  uaar,  boolaan  )  «  {11} 
var  USER-IAMB:  napC  uaar,  string  )  =  {||} 


rula  Add-Book-To-Library(  author  :  string, 

titla  :  acring, 
subjaet  *  sat(  string  )  ) 
anptyC  {  b  I  (b:  book)  book(  t  )  t 

titla-of-book(  b  )  «  titla  }  ) 

— > 

lat(  nav-book:  book  *  aaka-objaetC  'book  )  ) 
author-of-book  (  nan-book  }  <-  author; 
titla-of-book  (  nan-book  )  <-  titla; 
subjact-of-book(  nan-book  )  <-  subjaet; 
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on-shcll 

book-out 


(  nea-book  )  <-  true; 
(  new-book  )  <-  false 


rule  Reaove-Book-Froa-LibraryC  book-title  :  string  ) 

'eaptyC  {  b  I  (b;  book)  book(  b  )  k 

title-ol-book(  b  )  =  book-title  }  ) 

— > 

let(  book-to-delete:  book  =  arb(  {  b  |  (brbook) 

book(b)  t  title-ol-book(b)  *  book-title  }  ) 

) 

erase-object (  book-to-delete  ) 


rule  Add-User(  users-naae  :  string, 
on-staff  :  boolean  ) 
eapty(  {  u  I  (u:  user)  userCu)  ft 

user-naae(u)  =  users-naae  }  ) 

“> 

let(  nev-user:  user  «  aake-object(  'user  )  ) 
user-naaeC  new-user  )  <-  ueers-naae; 
staff (  new-user  )  <-  on-staff; 
custoaerC  new-user  )  <-  *on-staff 


rule  Reaove-User(  users-naae  :  string  ) 

‘eaptyC  {  u  I  (u:  user)  user(  u  )  ft 

user-naae(  u  )  ^  users-naae  >  ) 

— > 

let(  user-to-delete:  user  >  arb(  {  u  I  (u:  user) 
user(  u  )  ft  user-naae(  u  )  =  users-naae}  ) 

) 

erase-object(  user-to-delete  ) 


rule  Check-Out-Book (  whos-asking:  string, 

users-naae:  string, 
which-book:  string  ) 

'eaptyC  {  u  I  (u:  user) 

user(  u  )  ft  user-naaeC  u  )  =  whos-asking  } 

)  ft 

'MiptyC  {  u  I  (u:  user) 

userC  u  )  ft  user-naae(  u  )  =  users-naae  } 

)  ft 

‘eaptyC  {  b  I  (b:  book) 

bookC  b  )  ft  title-of-book(  b  )  =  which-book  } 

) 

— > 

staff  (  {  u  I  (u:  user) 

userC  u  )  ft  ttser-naaeC  u  )  =  whos-asking  }  ) 

)  ft 
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on-th«lf(  «rb(  {  b  I  (b:  book) 

book(  b  )  k  titl«-ol-book(  b  )  =  ■hich-book  }  ) 

) 

> 

l«t(  book-to-ch*ck-ottt :  book  =  axb( 

{  b  i  (b:  book)  book(  b  )  k 

titl*-of-book(  b  )  s  which-book  }  ) 

) 

on-ah«ll(  book-to-chock-out  )  <-  falao; 
book-out  (  book-to-chock-out  )  <-  tru*; 
lMt-ch«ck«d-out-by(  book-to-ch*ck-out  ) 

<-  uitra-naao 


rula  Raturn-Book(  vhoa-aaking:  string,  vhich-book:  string  ) 
~SBpty(  {  u  I  (u:  uaar) 

ussr(  n  )  k  uaar-naaia(  u  )  ~  shos-asking  > 

}  k 

*aBpty(  {  b  I  (b:  book) 

book(  b  )  k  titla-of-book(  b  )  =  shich-book  } 

) 

“> 

staff (  arb(  {  u  I  (u:  usar) 

assr(  u  )  k  utar-nasaC  u  )  *  shos-aaking  }  ) 

)  k 

book-out  (  arb(  {  b  I  (b:  book) 

book(  b  )  k  titla-of-book(  b  )  =  which-book  }  ) 
) 

— > 

lat  (  book-to-ba-ratumad:  book  >  arb( 

{  b  I  (b:  book)  book(  b  )  k 
titla-of-book(  b  )  =  which-book  }  ) 

) 

on-shclf(  book-to-ba-ratumad  )  <-  true; 
book-out  (  book-to-ba-ratumad  )  <-  falsa 


function  PRI1T-B00K-SET(  sat-of-books:  sat  (book)  )  = 
if(  aaiptyC  sat-of-books  )  )  than 

formate  trua,  "This  sat  of  books  is  ampty  ’X"  ) 

alaa 

anumarata  b  owar  sat-of-books  do 

formate  trua,  "iUTHOR:  ‘S  '30T  Tin.E:  'S 

"lOT  SUBJECT;  'S  'X", 
author-of-book(  b  ), 
titls-of-book(  b  ), 
subjact-of-book(  b  ) 

) 
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function  PRIIT-USER-SET(  sot-ol-utors:  sot (user)  }  * 
if(  raptyC  ■•t-of-uiors  )  }  thon 

fonat(  true,  "This  sst  of  users  is  enpty"  ) 

else 

enunerste  u  over  set-of-users  do 
fonat(  true,  user-naaeC  u  )  ) 


function  Books-On-Subject(  vhich-subject:  string  )  = 
print-book-set(  {  b  I  (  b:  book) 
book(  b  )  t 

{shich-subject}  subset  subject-of-book(b)  } 

) 


function  Books-By-Author(  vhich-suthor:  string  )  > 
print -book-set(  {  b  I  (  b:  book  ) 
book(  b  )  k 

suthor-of-book(  b  )  *  vhich-author  > 

) 


function  Booka-Checked-Out-By-User(  vhos-asking  ;  string, 

users-naae  ;  string  )  = 

if(  'eaptyC  {  u  I  (u:  user) 

user(  u  )  *  ttser-naneC  u  )  >  vhos-asking  } 

)  ft 

* enpty (  {  u  I  (u:  user) 

*  user(  u  )  ft  user-nane(  u  )  «  users-naae  } 

)  ft 

(  staff (  arb(  {  u  I  (u:  user) 

userC  u  )  ft  user-naaeC  u  )  «  vhos-asking  }  ) 

)  or 

vhos-asking  =  users-naae  )  ) 

than 

print-book-set (  {  b  I  (b:  book) 
book(  b  )  ft 
book-out (  b  )  ft 

users-naae  -  last-checked-out-by(  b  )  }  ) 

else 

foraatC  true, 

"You  are  not  authorized  access  to  that  inforaation" 

) 
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Appendix  H.  Visual  Refine  Specification  for  Place  s  Solution  to 

Kemmer's  Library  Problem 

This  appendix  contains  a  complete  Visual  Refine  Representation  for  the  Refine 
Specification  to  Kemmers’s  library  problem  found  in  Appendix  G. 
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Figure  H.l.  Visual  Refine:  Add- Book-To- Library 

* 
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Figure  H.2.  Visual  Refine:  Remove- Book- From- Library 
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Figure  H.3.  Visual  Refine;  Add-User 
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Figure  H.4.  Visual  Refine:  Remove-User 
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Figure  H.5.  Visual  Refine:  Check-Out-Book 
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Figure  H.6.  Visual  Refine;  Return-Book 
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Figure  H.7.  Visual  Refine:  Print-Book-Set 


Figure  H.8,  Visual  Refine:  Print- User- Set 
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Figure  H.9.  Visual  Refine:  Books-On-Subject 


Figure  H.IO.  Visual  Refine:  Books- By- Author 
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Figure  H.ll.  Visual  Refine:  Books- Checked- Out- By- User 


Appendix  1.  Blankenship  s  Refine^^  Specification  for  Kemmerer  s 

Library  Problem 

This  appendix  contains  a  Refine  specification  for  Kemmerer’s  library  problem 
discussed  in  Chapter  IV.  This  specification  is  a  slightly  modified  version  of  Blanken¬ 
ship’s  Refine  specification  found  in  (6:Appendix  db).  The  ‘set-attr’  Refine  construct 
is  not  supported  in  Visual  Refine  and  had  to  be  modified  into  a  block  of  assign¬ 
ment  statements  whenever  used  by  Blankenship.  Additionally,  Blankenship  used 
the  Refine  symbol  data  type  in  several  places.  Visualization  of  symbols  is  also  not 
supported  in  Visual  Refine;  therefore  symbols  were  converted  to  strings  as  necessary 
to  allow  for  a  visualization  of  Blankenship’s  library  problem  solution. 

1. 1  Declarations 


•!  in-packag«('’RU") 

!!  in-gr«nar(’tti«r} 

constant  BOOK-LIMIT: int agar  =  6 

V. - 

var  Library-World:  obj act-class  aubtypa-ol  usar-objact 
var  Library-Systan:  obj  act-class  subtypa-ol  Library-World 


var  Usar:  objact-class  aubtypa-of  Library-World 

var  Book:  objact-class  subtypa-of  Library-World 


% - 

var  Isusa:  aapC  Usar,  string  )  =  {11} 

var  Book-Connt:  aapCUsar,  intagar  )  =  {11} 

var  U-Typa:  napC  Usar,  string  )  =  {11} 

%%  changad  U-Typa  froa  syabol  to  string  lor  Visual  Kalina 

%X  {  ’Ordinary,  'Stall  } 


y. - 

var  Kay:  aapC 

var  Author:  nap( 

var  Titla:  aapC 

var  Sub j act:  aapC 


Book,  string) 

Book,  string) 

Book,  string) 

Book,  sat (string)) 


{11} 

{ll} 

{ll} 

{||} 


I-l 


var  Status:  aapC  Book,  string)  -  <11} 

var  Last-Utsr:  aapC  Book,  string)  -  <11} 

XX  changad  Status  from  sjabol  to  string  for  Visual  Refine 
XX  <  'Available,  'Checked-out  } 

X - 

var  Current-User:  aapC  Library-System,  User)  -  <l|} 

X - 

fora  Unique-Objects 

unique-naaes-classC  'User,  true  )  t 

uniqua-naaes-classC  'Book,  true  ) 

X - 

vau:  LS  :  Library-Systea  *  aake-object(  'Library-System  ) 


/.£  Internal  Utility  Functions 


function  PP-BooksCset-of-Book-objects:  set(Book)  )  - 
if  eapty(set-of-Book-objeets) 

then  foraatC  true,  "lo  Book  Objects  ’X"  ) 
else  enuaerate  Bk  over  set-of -Book-objects  do 
foraatC  true,  "Book  *  'WppW",  Bk) 


X - 

function  PP-User  (set-of -User-objects:  set  (User)  )  * 
if  eapty(set-of-User-objects) 

then  fomat(  true,  "lo  User  Objects  'X"  ) 
else  enuaerate  Us  over  set-of -User-objects  do 
fomat(  true,  "User  =  'WppW",  Us) 


X 


function  PP-Library(set-of-Library-objects:  set  (Library-World)  ) 
if  anpty(set-of-Library-objects) 

then  foraatC  true,  "lo  Library  System  Objects  'X"  ) 
else  enuaerate  Lib  over  set-of -Library-obj  ects  do 
foraatC  true,  "Library  System  =  'WppW",  Lib) 


X - 

fimction  Shov-LibO  * 

true  — >  PP-Library(  {  LIB  I  (  LIB:  Library-World  ) 
Library-World(LIB)  >  ) 


X 
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ml*  Init-Ui«r  (  Ui:  Ut«r. 

Z-lu«:  string, 

Z-Book-Count ;  intsgsr, 

Z-U-Typs:  string 

) 

■Valid-Ussr?(Z-Iaiis) 

— > 

lansC  Us  )  =  Z-Vas.#  k 

Book-Count (  Us  }  =  Z-Book-Count  k 
U-Typs(  Us  )  =  Z-U-Typs 

•/. - 

ruls  Init-Book  (  Bo:  Book, 

Z-Ksy:  string, 

Z-Author :  string , 

Z-Titls:  string, 

Z-Subjsct:  sst (string), 

Z-Status :  string 

) 

•Valid-Book? (Z-Ksy) 

--> 

Ksy(  Bo  )  »  Z-Ksy  * 

Author (  Bo  )  *  Z-Author  A 

Titls(  Bo  )  *  Z-Titls  t 

Sub j set (  Bo  )  =  Z-Subjsct  * 

Status (  Bo  )  =  Z-Status  k 

Last-Ussr(  Bo  )  *  "  " 

y. - 

function  Valid-Ussr?(Z-Iaao  :  string) rboolsan  - 
*sBipty({  u  I  (u:  ussr)  ussr(u)  k  Mans(u)  =  Z-laas}) 

y. - 

function  Find-UssrCZ-Iaas  :  string)  :  Ussr  = 

arb(  {u  I  (u:ussr)  ussr(u)  k  lasisCu)  =  Z-Ians}) 

y. - 

function  Staff-Opsrator?(Z-Ussr  :  ussr)  :bools&n  = 
U-Typs(Z-Ussr)  ■  "Staff" 

y. - 

function  Valid-Book? (Z-Ksy  :  string)  :  boolsan  * 
"s«pty({  b  I  (b:book)  book(b)  k  Ksy(b)  *  Z-Ksy  }) 

y. - 


1-3 


function  Find-Book  (Z-K«y  :  string)  :  book  = 

arb(  {  b  I  (b:book)  book(b)  k  Ksy(b)  »  Z-Ksy  }} 


% - 

function  Undsr-Book-Liait?(Z-Us«r: string)  :boolsan  & 
Book-Count (Find-User (Z-Us«r))  <  BOOK-LIMIT 


7. 


function  Book-Available? (Z-Ksy  : string)  : boolean  = 
Status(Find-Book(Z-Key))  =  "Available" 


7. 


1.3  Internal  Library  Support  Functions 


function  Check-Out (Z-User  :  string, 

Z-Key  :  string  )  s 
Valid-User? (Z-User)  * 

Under-Book-LiBit?(Z-User)  t 
Book-Available? (Z-Key) 

— > 

Status (Find-Book (Z-Key))  *  "Checked-Out"  t 
Last-User (Find-Book(Z-Key))  =  Z-User  * 

Book-Count (Find-User (Z-User))  *  Book-Count (Find-User (Z-User))  +  1 


7. 


function  Check-In-Book(Z-Key  :  string  )  - 
'Book-Available? (Z-Key) 

--> 

Status (Find-Book(Z-Key))  *  "Available"  * 

Book-Count  (Find-User(last-User(Find-Book(Z-Key))))  = 

Book-Count(Find-User(Last-User(Find-Book(Z-Key))))  -  1 


X - 

function  Nake-Book(Z-Key: string)  « 

'Valid-Book? (Z-Key) 

— > 

init-book (Nake-Ob j  ect ( ' Book) , 

Z-Key, 

read-a-string("Input  the  lev  Book's  Author"), 
read-a-string("Input  the  lev  Book's  Title"), 
read-a-set-of-strings( 


1-4 


"Input  th«  IM  Book's  Subjsct  Arsas"0ns  per  line"), 
"iTsilable" 

) 


% - 

function  Delete-Book(Z-Key: string)  = 
Valid-Book?(Z-Key)  k 
Book-Available? (Z-Key ) 

— > 

Eras  e-Ob j  ect (Find-Book ( Z-Key) ) 


y. 


function  Books-By-Author(Z-Author: string)  ^ 
PP-Books(  {  b  I  (b:book)  book(b)  k 

Author (b)  *  Z-Author  }  ) 


y. 


function  Books-By-Subject(Z-Subject: string)  > 
PP-Books(  {  b  I  (b:book)  book(b)  k 

{Z-Subject}  subset  Subject (b)  }  ) 


X - 

function  Borroved-Books(Z-Iaae: string)  * 
Valid-User? (Z-laae) 

— > 

PP-Books(  {  b  I  (b:book)  book(b)  * 
Last-User(b)  =  Z-laae  }  ) 


y. 


function  Last-Borro*er(Z-Key: string)  ~ 
Valid-Book? (Z-Key) 

— > 

PP-Books(  {  b  I  (b;book)  book(b)  t 
Key(b)  *  Z-Key  }  ) 


X - 

function  Make-User (Z-Iane:  string)  * 

'Valid-User? (Z-Iaae) 

— > 

init -us  er  ( Nake-Ob  j  ect  ( '  Us er ) ,  Z-Iane ,  0 , " Ordinary" ) 


y. 


function  Delete-Usor(Z-laBa: string)  - 
Valid-User?(Z-laBe)  k 
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Book-Connt(Fiiid-Us«r(Z-laB«))  *  0 
— > 

Erat«-Ob j  cct (Find-Ut cr ( Z-lam*) ) 


1.4  Externally  Visable  Library  Rules 


ml*  login(z:obj«ct) 

undtf in*d? (Cttrr*nt-U*«r (z ) ) 

— > 

Curr«nt-Us«r(z)  «  Find-U**r(r*ad-a-string('*Input  Your  laa*")) 


y. 


ml*  logout  (z:obj*ct) 

d*l in*d? ( Curr *nt-Uf  *r ( z ) ) 

— > 

Curr*nt-U**r(z)  «  und*lin*d 


% - 

ml*  Add-Book(z:obj*ct) 

Staff*Op*rator?(CarT*nt-U**r(z)} 

— > 

Nak*-Book(r«ad-a-strlng("Input  tb*  l*v  Book'*  K*7")  ) 


y. 


rul*  Reaov*-Book(z:obj*ct) 

Stal  f-Op*rator?  (Curr*zit-UB*r(z)  ) 

— > 

D*l*t*-Book(r*ad-a-atring("Input  th*  Book's  Koy  to  d*l*t*")  ) 


% - 

ml*  Add-Us*r(z:obj*ct) 

Stalf-Op*rator?  (Curr*iit-Us*r  (z)  ) 

— > 

Mak*-Us*r(r*ad-a-string("Input  th*  l*w  Ustr's  laa*")) 


X - 

ml*  R«aov*-UB*r(z:obj*ct) 

Staff  Op*rator?(Curr*nt-Us*r(z)) 

— > 

D*lBt*-Us*r(r*ad-a-string(”Input  th*  Us*r*B  laa*  to  d*l*t*")  ) 
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% - 

rul«  Ch«ck-Out-Book(z: object) 

Staf  l-0p«rator?(CnzT«nt-U8er(z) ) 

— > 

Ch«ck-Out(r«ad-a-atrlng("Input  the  Parson's  lane"), 
raad-a-string("Input  the  Book’s  Kay")  ) 


y. 


rule  Rat\im-Book(z: object) 

Stafl-Operator?(Currant-Uaar(x)) 

— > 

Chack-In-Book(raad-a-8tring("Input  the  Book's  Kay  to  Delete")) 


y. 


rule  List-Books-By-Author(z: object) 

Valid-User? (laae(Current-User(x))) 

— > 

Books-By-ittthor(read-a-string( "Input  the  Desired  Author’s  lane")) 


y - 

rule  List-Books-By-Sub j  act  (x :  ob j  act ) 

Valid-User? (lane (Current-User (x) ) ) 

— > 

Books-By-Subject(read-a-string("Input  the  Desired  Subject  Area")) 


y - 

rule  List-Borrowed-Books(x .'Object) 

Staff -Operator? (Current-User(x) ) 

— > 

Borrowed-Books(read-a-string("Input  the  Desired  User's  lane")) 


y 


rule  List-Ny-Borrowed-Books(x: object) 

Val id-User ? ( lane ( Curr ent-Us  er ( X ) ) ) 

~> 

Borroved-Books  (laneCCurrent-User  (X)  ) ) 


y - 

rule  List -Last-Borro«er ( x : ob j  act ) 
Staff-Qperator?(Current-User(x)) 

“> 

Last-Borrower(road-a-string("Input  the  Desired  Book's  Key")) 
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Appendix  J.  Visual  Refine  Specification  for  Blankenship ’s  Solution 

to  Kemmer’s  Library  Problem 

This  appendix  contains  a  complete  Visual  Refine  Representation  for  the  Refine 
Specification  to  Kemmers’s  library  problem  found  in  Appendix  I. 


J.I  Internal  Utility  Functions 


'■J  L 


0? 


Setjof-Book-Objej:ts 


iiffit- 


No  Book  Objects  **% 


Book-Object 


Figure  J.I.  Visual  Refine:  PP-Books 


No  User  Objects  -% 


I®)* 


Us6r-0bj9ct 

r 

Figure  J.2.  Visual  Refine:  PP-User 


(©OQ) 


Figure  J.3.  Visual  Refine:  PP-Library 


(oom 


®o 


Figure  J.6.  Visual  Refine:  Init-Book 
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Figure  J.7.  Visual  Refine:  Valid-User? 
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Figure  J.8.  Visual  Refine:  Valid-Book? 
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Figure  J.IO.  Visual  Refine:  Find- Book? 
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Figure  J.ll.  Visual  Refine:  Staff-Operator? 


J-10 


Book-Limit 


Figure  J.12.  Visual  Refine:  Under-Book- Limit? 


Figure  J,13.  Visual  Refine:  Book-Available? 


J-12 


<oo 


J.2  Internal  Library  Support  Functions 


Figure  J.14.  Visual  Re'ine:  Check-Out 
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Figure  J. 15.  Visual  Refine:  Check-In-Book 
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Figure  J.16.  Visual  Refine:  Make-User 
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Figure  J. 17.  Visual  Refine:  Make-Book 
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Figure  J.18.  Visual  Refine:  Delete-User 
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Figure  J.19.  Visual  Refine:  Delete- Book 
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Z-Aultxy 


PP-BooKs 


I  L' 
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AND 


Figure  J.20.  Visual  Refine:  Books-By-Author 
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Figure  J.21.  Visual  Refine:  Books-By-Subject 
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Figure  J.22.  Visual  Refine:  Borrowed- Books 
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Figure  J.23.  Visual  Refine:  Last-Borrower 
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J.3  Externally  Visablt  Library  Rules 


Figure  J.24.  Visual  Refine:  Login 


Figure  J.25.  Visual  Refine:  Logout 
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OCXD; 


‘  Input  thcNmvUMr'iNme’ 


Figure  J.26.  Visual  Refine:  Add-User 


'  Input  th«  N«w  Book*!  K«y  * 

Figure  J.27.  Visual  Refine:  Add-Book 


J-24 


'  Input  th«UM('i  NametodeMe’ 

Figure  J.28.  Visual  Refine:  Remove-User 


'  Input  the  Book’s  Key  to  delete  ’ 

Figure  J.29.  Visual  Refine:  Remove-Book 
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"  Input  the  Book’s  Key  to  Return  *  •  Input  the  Book’s  Key  to  Return  ’ 

Figure  J.30,  Visual  Refine:  Check-Out-Book 
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■  Input  the  Book’s  Key  to  Return  • 


Figure  J.31.  Visual  Refine;  Return-Book 
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'  Input  the  Desired  Author's  Name ' 

Figure  J.32.  Visual  Refine:  List-Books-By-Author 
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'  Input  the  Desired  Subject  Area  * 

Figure  J.33.  Visual  Refine:  List- Books- By-Subject 


Figure  J.34.  Visual  Refine:  List-Borrowed-Books 


Figure  J.35.  Visual  Refine:  List-My-Borrowed-Books 


*  Input  th«  Owirvd  Book’s  K«y  * 

Figure  J.36.  Visual  Refine:  List-Last-Borrower 
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